From mailman-bounces@ietf.org Sun Aug 1 08:26:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17349 for ; Sun, 1 Aug 2004 08:26:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCiD-0003Sj-Ky for dhcipv6-archive@lists.ietf.org; Sun, 01 Aug 2004 05:33:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: dhcipv6-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:09:18 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhcipv6-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org xJod https://www1.ietf.org/mailman/options/dhcwg/dhcipv6-archive%40lists.ietf.org From dhcwg-bounces@ietf.org Sun Aug 1 12:32:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09530; Sun, 1 Aug 2004 12:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrJA8-0003aQ-7S; Sun, 01 Aug 2004 12:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHsx-0005K7-KF for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 11:04:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05268 for ; Sun, 1 Aug 2004 11:04:25 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrHvd-0004Mo-7G for dhcwg@ietf.org; Sun, 01 Aug 2004 11:07:13 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71F3mA31984; Sun, 1 Aug 2004 18:03:48 +0300 Date: Sun, 1 Aug 2004 18:03:48 +0300 (EEST) From: Pekka Savola To: mboned@lists.uoregon.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-Mailman-Approved-At: Sun, 01 Aug 2004 12:26:13 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, A few comments. Bigger ones: 1) I'm concerned whether this is exactly what we need, especially when we have RFC3306 or embedded-RP; it is not clear which problem we're solving (and which problems remain to be solved). In particular, if any host on a link with a /64 prefix could calculate its own multicast prefix (unique to that link) on its own, and have 32 bits of group-id's to pick from (making sure they don't conflict on that link), could one argue that there is no need for central multicast address assignment.. but rather a mechanism where the host could pick a group-id in such a way it doesn't conflict (a random process should be sufficient, but if not, there could be Multicast DAD)? Similarly, if embedded-RP is used, what you could need is the information what is the address of the RP or which prefix one should use for picking the multicast addresses. So, looking at from a different perspective, it would seem that we don't necessarily need DHCPv6 for address assignment itself, but maybe some other configuration mechanism to figure out the multicast prefix which belongs on the link. Remember, we're talking about v6 here which is completely different than v4 multicast address assignment scenarios (address scarcity, centrally managed pool, etc.)! 2) I think this approach and its implications could use a bit more discussion inside mboned (which is why I argue splitting it up makes sense). In particular, the assignment of addresses is also coupled with service discovery/announcements, which was decreed out of scope from here. But as DHCPv6 servers can even update DNS records, it could be possible to envision that if they give out v6 multicast addresses as well, they might be capable of other difficult tasks as well. (If the document is split, it might make sense to keep sections 1-4 in mboned, and include new section 5 which would describe different new approaches to these scenarios -- e.g., various uses of DHCPv6, multicast-DAD, the embedded-RP communicating the address at which it's serving (e..g, if on every link, the ::1 one) ...) 3) o DHCPv6 usually has impacts on the kernel (IPv6 unicast addressM assignment, DNS address indication...) and the problem ofM multicast address assignment is in user space. Are there someM problems that could be coming from this ?M ==> this brings out a lurking issue. As v6 multicast addresses are given out only temporarily, with lifetime, the question is, who keeps track of that lifetime and removes the usage as appropriate? In other words, I assumed that this approach assumes that when an app wants to use a multicast address, the user/administrator of that application puts in a request in DHCPv6, and gets a (temporary) address. (S)he then configures it in the application, and runs the application. But then there is no link with the lifetime of the address. The other approach would probably be to make it more complex, adding some kind of API between DHCPv6 and multicast application, but that would probably be a non-starter due to its complexity. In any case, it seems the impact of lifetime needs to be considered a bit more deeply... semi-substantial ---------------- option-code: OPTION_IA_MA (21)M ==> have these option codes already been assigned by IANA, or are you just suggesting to use these? Should probably be replaced by TBD's, and noted in IANA Considerations section to be added. editorial --------- ==> IMHO, the abstract should be a bit longer, maybe 5-10 lines. o This random assignment could also be used with embedded RPM addresses if the RP is managing a few number of groupsM ==> as noted above in issue 1), this might not be as straightforward that, as the host needs to know the RP's Interface-ID (at least) first-- possibly also which kind of prefix to use.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-M +M | M |M . IA_MA-options M =2EM . M =2EM +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-M ==> this seems to have wrapped, and there are some =2E chars here.. know exactely the scope it wants to request but has a set of adequatM ==> s/adequat/adequate/ res: This field is reserved for future use. The 4 bits of this fieldM MUST be set to 0M ==> , and MUST be ignored on receipt. (similar elsewhere) Security and pricacy considerations of the assignment of IPv6M ==> s/pricacy/privacy/ o Split in 2 different drafts: one for the DHC WG with theM description of the DHCPv6 options and mechanismsand; the other oneM ==> s/and/ and/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 1 14:10:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14068; Sun, 1 Aug 2004 14:10:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrKj8-0006Um-3h; Sun, 01 Aug 2004 14:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrKO4-0007Cr-Nh for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 13:44:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13163 for ; Sun, 1 Aug 2004 13:44:41 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrKQk-0006Vg-Tz for dhcwg@ietf.org; Sun, 01 Aug 2004 13:47:32 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i71HiAV0017729; Sun, 1 Aug 2004 19:44:10 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i71Hi9CE015056; Sun, 1 Aug 2004 19:44:09 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Sun, 1 Aug 2004 19:44:09 +0200 From: Stig Venaas To: Pekka Savola Message-ID: <20040801174409.GB14995@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sun, Aug 01, 2004 at 06:03:48PM +0300, Pekka Savola wrote: [...] > have RFC3306 or embedded-RP; it is not clear which problem we're solving > (and which problems remain to be solved). > > In particular, if any host on a link with a /64 prefix could calculate its > own multicast prefix (unique to that link) on its own, and have 32 bits of > group-id's to pick from (making sure they don't conflict on that link), > could one argue that there is no need for central multicast address > assignment.. but rather a mechanism where the host could pick a group-id in > such a way it doesn't conflict (a random process should be sufficient, but > if not, there could be Multicast DAD)? Yes, I've also thought a bit about this. The 64-bit link-id could be a starting point too. I think some form of DAD would be nice. It must also be possible for a host to have multiple groups. > Similarly, if embedded-RP is used, what you could need is the information > what is the address of the RP or which prefix one should use for picking the > multicast addresses. > > So, looking at from a different perspective, it would seem that we don't > necessarily need DHCPv6 for address assignment itself, but maybe some other > configuration mechanism to figure out the multicast prefix which belongs on > the link. Yes, sounds good. So question then is whether DHCP or something else should be used. WRT Embedded-RP I think allocating a prefix to the link, as you suggest, is better than telling the application what the Embedded-RP address is (applications shouldn't need to know about Embedded-RP details). I see some possible issues. There might be a need for giving hosts different prefixes for different scopes (you could imagine having one prefix where simply the scope bits are set to whatever scope is needed). I think there are cases where you might use say Embedded-RP internally (with small scope) and prefix-based addressing externally (with larger scope) or vice versa. Or where you may want different RPs for different scopes. Well, in short, I also think the fact that we only need uniqueness per link, should simplify things quite a bit. I would be happy to work on possible solutions to this. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 1 15:24:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18620; Sun, 1 Aug 2004 15:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrLop-00013T-Hl; Sun, 01 Aug 2004 15:16:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrLPX-0003FH-3Q for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 14:50:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15653 for ; Sun, 1 Aug 2004 14:50:15 -0400 (EDT) Received: from dmzraw2.extranet.tce.com ([157.254.234.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrLSD-0007Cm-RL for dhcwg@ietf.org; Sun, 01 Aug 2004 14:53:07 -0400 Received: from smtprelay.indy.tce.com (ismtprelay.indy.tce.com [157.254.96.114]) by dmzraw2.extranet.tce.com (8.12.5/8.12.5) with ESMTP id i71InZgG023236; Sun, 1 Aug 2004 18:49:37 GMT Received: from boulsmailbh02.eu.thmulti.com (localhost [127.0.0.1]) by smtprelay.indy.tce.com (8.9.3/8.9.1) with ESMTP id SAA09084; Sun, 1 Aug 2004 18:49:34 GMT Received: from edgmsmsg01.eu.thmulti.com ([141.11.248.11]) by boulsmailbh02.eu.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 Aug 2004 20:49:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Comments ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-imap-00.txt Date: Sun, 1 Aug 2004 20:49:33 +0200 Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168D0C@edgmsmsg01.eu.thmulti.com> Thread-Topic: [dhcwg] Comments ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-imap-00.txt Thread-Index: AcR2VUXrEf7CPT9NTz+/AsATj3a7xwBoURQQ From: "Van Aken Dirk" To: "Ted Lemon" , "Cristian Cadar" X-OriginalArrivalTime: 01 Aug 2004 18:49:33.0561 (UTC) FILETIME=[491F7690:01C477F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Ted, Cristian, See some comments inline. Best regards - Dirk > -----Original Message----- > From: dhcwg-bounces@ietf.org=20 > [mailto:dhcwg-bounces@ietf.org]On Behalf Of > Ted Lemon > Sent: vrijdag 30 juli 2004 18:33 > To: Cristian Cadar > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Comments > ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt- > imap-00.txt > =20 > I guess my first question about this is why? I assume to come closer to zero-config of hosts and applications I would = say. =20 > Why would you want a client to trust the DHCP server to tell you what = IMAP server to=20 > contact? Is this not true for all options that are returned by a server ? > What if you wind up talking to a rogue server, or roam to a=20 > different network? These don't seem like things that are=20 > location-dependent - they seem like things that you want to configure=20 > on the client and not change as the client moves around. True, but on the other hand from the perspective of a system admin, = he/she must use two methods for host/application configuration. That is, = a DHCP server for a first set of parameters and scripts or even manual = config for other parameters. >=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 From dhcwg-bounces@ietf.org Sun Aug 1 18:12:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27681; Sun, 1 Aug 2004 18:12:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrOUB-0000tI-SL; Sun, 01 Aug 2004 18:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrOOj-0002eg-Np for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 18:01:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26455 for ; Sun, 1 Aug 2004 18:01:38 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrORR-0001YX-Tw for dhcwg@ietf.org; Sun, 01 Aug 2004 18:04:31 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71M17V06867; Mon, 2 Aug 2004 01:01:07 +0300 Date: Mon, 2 Aug 2004 01:01:06 +0300 (EEST) From: Pekka Savola To: Stig Venaas In-Reply-To: <20040801174409.GB14995@sverresborg.uninett.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sun, 1 Aug 2004, Stig Venaas wrote: [...] > I see some possible issues. There might be a need for giving hosts > different prefixes for different scopes (you could imagine having > one prefix where simply the scope bits are set to whatever scope > is needed). I think there are cases where you might use say > Embedded-RP internally (with small scope) and prefix-based addressing > externally (with larger scope) or vice versa. Or where you may want > different RPs for different scopes. Well, one obvious way to achieve all of this is to add a Multicast Prefix Information option (a tailed down version of PI option), to RFC2461/RFC2462 Route Advertisements, and specification of multicast DAD (possibly with a flag in the MPI whether it's needed or not). With that, multiple prefixes could be advertised, but typically one would be enough. (The "good news" here is that a good implementation would not need to require the router admin to specify the prefix to be advertised on all the links, but it could be calculated & advertised automatically as well.) Additionally, individual addresses could also be dealt with DHCPv6 or something, but I personally don't see that as equally attractive.. but in cases where this is attractive IMHO manual addressing, as it's done today, is probably typically more lucrative.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 1 22:12:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13714; Sun, 1 Aug 2004 22:12:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrSD8-0003dd-Pe; Sun, 01 Aug 2004 22:05:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrS4P-0008Vi-8e for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 21:56:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08780 for ; Sun, 1 Aug 2004 21:56:55 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrS78-0004f3-08 for dhcwg@ietf.org; Sun, 01 Aug 2004 21:59:49 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Aug 2004 21:56:22 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i721uKRK002600 for ; Sun, 1 Aug 2004 21:56:20 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn3-111.cisco.com [10.82.216.111]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKN56832; Sun, 1 Aug 2004 21:56:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20040801215319.0264fcd8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 01 Aug 2004 21:57:41 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [dhcwg] Final agenda for dhc WG meeting 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org PLEASE READ THE INTERNET DRAFTS ON THE AGENDA!!!! We need active participants, who have read the drafts BEFORE the WG meeting, so we can reach consensus on WG actions such as accepting drafts as WG work items and approving drafts for WG last call. We will need at least one 9and preferably more) scribe to take notes at the meeting. Is anyone who will not attend the meeting in San Diego interested in a jabber session? Please let me know as soon as possible. Final agenda: DHC WG agenda - IETF 60 0900 Tue 2004-08-03 (tentative) (Last revised 08/01/2004 09:48 PM) ---------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing, blue sheets, scribe, Jabber scribe Status of IPR claim by Samsung on draft-ietf-dhc-rapid-commit-opt-05.txt Status of IPR claim by PacketFront on draft-ietf-dhc-subscriber-id-06.txt Request for milestones for dhc WG drafts The DHCPv6 Client FQDN Option Bernie Volz 05 minutes Accept as dhc WG work item? The DHCP Client FQDN Option Bernie Volz 10 minutes Technical discussion DHCPv4 Opts. for B-cast and M-cast Control Servers Kuntal Chowdhury 05 minutes Accept as dhc WG work item? DHCPv6 Opts. for B-cast and M-cast Control Servers Kuntal Chowdhury 05 minutes Accept as dhc WG work item? DHCP Option for Configuring IPv6-over-IPv4 Tunnels S. Daniel Park 05 minutes Accept as dhc WG work item? Configured Tunnel End-Point Config. using DHCPv4 S. Daniel Park 05 minutes Accept as dhc WG work item? DHCP Option for Home Agent Discovery in MIPv6 Heejin Jang 05 minutes Accept as dhc WG work item? Vendor-Specific Information Suboption for RAIO Mark Stapp 05 minutes Accept as dhc WG work item? Renumbering Requirements for Stateless DHCPv6 Tim Chown 15 minutes Ready for WG last call? Lifetime Option for DHCPv6 Stig Venaas 15 minutes Ready for WG last call (depending on status of 'Renumbering Requirements')? IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Tim Chown 30 minutes Ready for WG last call? Issues in DHCPv6 authentication Jinmei Tatuya 15 minutes Technical discussion IPv6 multicast address assignment with DHCPv6 Jerome Durand 20 minutes Technical discussion ----------- 150 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 00:53:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29438; Mon, 2 Aug 2004 00:53:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrUnQ-0007mc-9q; Mon, 02 Aug 2004 00:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrUkw-0006K1-GP for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 00:49:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29295 for ; Mon, 2 Aug 2004 00:48:59 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrUni-0007H4-CP for dhcwg@ietf.org; Mon, 02 Aug 2004 00:51:56 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i724mQV0019796; Mon, 2 Aug 2004 06:48:26 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i724mPGu016973; Mon, 2 Aug 2004 06:48:25 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 2 Aug 2004 06:48:25 +0200 From: Stig Venaas To: Pekka Savola Message-ID: <20040802044825.GA16941@sverresborg.uninett.no> References: <20040801174409.GB14995@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 02, 2004 at 01:01:06AM +0300, Pekka Savola wrote: [...] > Well, one obvious way to achieve all of this is to add a Multicast > Prefix Information option (a tailed down version of PI option), to > RFC2461/RFC2462 Route Advertisements, and specification of multicast > DAD (possibly with a flag in the MPI whether it's needed or not). > > With that, multiple prefixes could be advertised, but typically one > would be enough. > > (The "good news" here is that a good implementation would not need to > require the router admin to specify the prefix to be advertised on all > the links, but it could be calculated & advertised automatically as > well.) The prefixes to use could also be announced by DHCP. You could easily use stateless DHCP. In addition to this some form of DAD would be good. I don't care that much how the client picks the last 32 bits, it could be random, from interface id somehow, or specified by the user. The main thing is making sure it's unique. So, I think there are basically two issues that can be solved independently. One is prefix to use, the other is link uniqueness. The former might be done with RAs or stateless DHCP. The second should probably be done using some link-local multicast ICMP, but I need to think more about that. One issue is that one needs to allow multiple sources for a group in some cases. So I think DAD should just be offered as a service, whether an application should use the group in case of duplicates should be up to the application. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 02:46:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18614; Mon, 2 Aug 2004 02:46:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrWQa-0002ZW-GF; Mon, 02 Aug 2004 02:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrWGv-0006CW-Dp for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 02:26:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17480 for ; Mon, 2 Aug 2004 02:26:08 -0400 (EDT) Received: from sinfonix.rz.tu-clausthal.de ([139.174.2.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrWJi-0008OS-H4 for dhcwg@ietf.org; Mon, 02 Aug 2004 02:29:03 -0400 Received: from [139.174.2.206] (balrog.rz.tu-clausthal.de [139.174.2.206]) by sinfonix.rz.tu-clausthal.de (8.9.3/8.9.3) with ESMTP id IAA21113 for ; Mon, 2 Aug 2004 08:26:05 +0200 (MET DST) Subject: Re: [dhcwg] Final agenda for dhc WG meeting From: Christian Strauf To: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20040801215319.0264fcd8@flask.cisco.com> References: <4.3.2.7.2.20040801215319.0264fcd8@flask.cisco.com> Content-Type: text/plain Organization: Rechenzentrum TU Clausthal Message-Id: <1091427965.17987.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 02 Aug 2004 08:26:05 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > Is anyone who will not attend the meeting in San Diego interested in a > jabber session? Please let me know as soon as possible. I'm very interested in a jabber scribe. Thanks in advance! Christian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 07:09:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29693; Mon, 2 Aug 2004 07:09:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BraeU-0007gu-NX; Mon, 02 Aug 2004 07:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrZE8-0005Og-TM for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 05:35:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25957 for ; Mon, 2 Aug 2004 05:35:27 -0400 (EDT) Received: from ns1.u-strasbg.fr ([130.79.200.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrZGx-0002Rm-QU for dhcwg@ietf.org; Mon, 02 Aug 2004 05:38:25 -0400 Received: from crc.u-strasbg.fr (crc6.u-strasbg.fr [IPv6:2001:660:2402:1001::1]) by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i729ZPvY099300 ; Mon, 2 Aug 2004 11:35:25 +0200 (CEST) Received: from crc.u-strasbg.fr (sixnet.u-strasbg.fr [130.79.90.153]) by crc.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i729ZOmg008944 ; Mon, 2 Aug 2004 11:35:25 +0200 (CEST) Message-ID: <410E0ADD.4050505@crc.u-strasbg.fr> Date: Mon, 02 Aug 2004 11:35:25 +0200 From: Jean-Jacques Pansiot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas References: <20040801174409.GB14995@sverresborg.uninett.no> <20040802044825.GA16941@sverresborg.uninett.no> In-Reply-To: <20040802044825.GA16941@sverresborg.uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Message not sent from an IPv4 address, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [IPv6:2001:660:2402::1]); Mon, 02 Aug 2004 11:35:25 +0200 (CEST) X-Antivirus: scanned by sophos at u-strasbg.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 02 Aug 2004 07:06:45 -0400 Cc: dhcwg@ietf.org, Pekka Savola , mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: >On Mon, Aug 02, 2004 at 01:01:06AM +0300, Pekka Savola wrote: >[...] > > >>Well, one obvious way to achieve all of this is to add a Multicast >>Prefix Information option (a tailed down version of PI option), to >>RFC2461/RFC2462 Route Advertisements, and specification of multicast >>DAD (possibly with a flag in the MPI whether it's needed or not). >> >>With that, multiple prefixes could be advertised, but typically one >>would be enough. >> >>(The "good news" here is that a good implementation would not need to >>require the router admin to specify the prefix to be advertised on all >>the links, but it could be calculated & advertised automatically as >>well.) >> >> > >The prefixes to use could also be announced by DHCP. You could easily >use stateless DHCP. In addition to this some form of DAD would be good. >I don't care that much how the client picks the last 32 bits, it could >be random, from interface id somehow, or specified by the user. The >main thing is making sure it's unique. > > One useful feature of DHCP is the notion of a lease for some amount of time. Assume that I want to start a videoconference tomorrow at 9am. It might be useful to reserve an address NOW (in order to publish it) although applications (senders and receivers) will be launched only to morrow.It seems that we have 3 solutions : 1) use some kind of centralized registry on the link (could be dhcp?) 2) have a local registry on each host, could be similar to a dhclient.leases file, but then it might need a new daemon to respond to multicast DAD ? this should be persistent across crashes and reboot 3) do a multicast DAD now and hope it will still work tomorrow ? What do you think ? Note that mechanism 2 could be useful also for SSM : it allows a user to reserve a channel without conflict with other node-local users/applications Jean-Jacques >So, I think there are basically two issues that can be solved >independently. One is prefix to use, the other is link uniqueness. > >The former might be done with RAs or stateless DHCP. The second >should probably be done using some link-local multicast ICMP, but I >need to think more about that. One issue is that one needs to allow >multiple sources for a group in some cases. So I think DAD should >just be offered as a service, whether an application should use the >group in case of duplicates should be up to the application. > >Stig >_______________________________________________________________ >user interface: http://darkwing.uoregon.edu/~llynch/mboned.html >web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 18:54:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12220; Mon, 2 Aug 2004 18:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brisg-0000op-Lb; Mon, 02 Aug 2004 15:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Briog-0007Fp-Hi for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 15:49:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00200 for ; Mon, 2 Aug 2004 15:49:48 -0400 (EDT) Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrirZ-00039o-N6 for dhcwg@ietf.org; Mon, 02 Aug 2004 15:52:52 -0400 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i72Jp9wF020526 for ; Mon, 2 Aug 2004 12:51:09 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Mon, 2 Aug 2004 12:49:15 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i72JnCQg004282; Mon, 2 Aug 2004 12:49:13 -0700 (PDT) Message-Id: <200408021949.i72JnCQg004282@relay4.apple.com> Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Mon, 2 Aug 2004 12:49:15 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Ted Lemon" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: DHCP discussion list 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >I think it's worth having a standard that says what the right thing to >do is. Stuart's draft seemed like a good candidate, but did not get >widespread support from the DHC working group, if I remember correctly. I would say it got luke-warm support. I plan to update the draft, as soon as I get time. > There was also some question as to whether it was even on-topic for >the working group, since it actually changes the semantics of ARP >somewhat. No, it doesn't change ARP semantics in any way. Everything it recommends is 100% consistent with RFC 826. The question of whether to announce via ARP request or response is something that really doesn't matter, and is therefore the thing guaranteed to generate the greatest amount of debate. As John Schnizlein correctly pointed out, "RFC 826 explicitly does not discriminate between request or reply messages before updating its table". Here's what I plan to put in the next draft: Why are ARP Announcements performed using ARP Request packets and not ARP Reply packets? There are two reasons, one is historical precedent, and the other is practicality. The historical precedent is that Gratuitous ARP is described in Stevens Networking [Ste94] as using ARP Request packets. What Stevens describes as Gratuitous ARP is what this document calls an ARP Announcement. BSD Unix, Windows, Mac OS 9, Mac OS X, etc. all use ARP Request packets as described in Stevens. At this stage, trying to mandate that they all switch to using ARP Reply packets would be futile. The practical reason is that ARP Request packets are more likely to work correctly with more existing ARP implementations, some of which may not implement RFC 826 correctly. The Packet Reception rules in RFC 826 state that the opcode is the last thing to check in packet processing, so it really shouldn't matter, but there may be "creative" implementations that have different packet processing depending on the ar$op field, and there are several reasons why these are more likely to accept gratuitous ARP Requests than gratuitous ARP Replies: * An incorrect ARP implementation may expect that ARP Replies are only sent via unicast. RFC 826 does not say this, but an incorrect implementation may assume it, and the "principle of least surprise" dictates that where there are two or more ways to solve a networking problem that are otherwise equally good, the one with the fewest unusual properties is the one likely to have the fewest interoperability problems with existing implementations. An ARP Announcement needs to broadcast information to all hosts on the link. Since ARP Request packets are always broadcast, and ARP Reply packets are not, receiving an ARP Request packet via broadcast is less surprising than receiving an ARP Reply packet via broadcast. * An incorrect ARP implementation may expect that ARP Replies are only received in response to ARP Requests that have been issued recently by that implementation. Unexpected unsolicited Replies may be ignored. * An incorrect ARP implementation may ignore ARP Replies where ar$tha doesn't match its hardware address. * An incorrect ARP implementation may ignore ARP Replies where ar$tpa doesn't match its IP address. In summary, there are more ways that an incorrect ARP implementation might plausibly reject an ARP Reply (which usually occurs as a result of being solicited by the client) than an ARP Request (which is already expected to occur unsolicited). Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 18:54:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12259; Mon, 2 Aug 2004 18:54:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brixi-0002ua-Mx; Mon, 02 Aug 2004 15:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BriuX-0001Zp-2u for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 15:55:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00383 for ; Mon, 2 Aug 2004 15:55:51 -0400 (EDT) Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrixR-0003E2-H0 for dhcwg@ietf.org; Mon, 02 Aug 2004 15:58:54 -0400 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i72JvETL021830 for ; Mon, 2 Aug 2004 12:57:14 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Mon, 2 Aug 2004 12:55:20 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i72JtILu021742; Mon, 2 Aug 2004 12:55:19 -0700 (PDT) Message-Id: <200408021955.i72JtILu021742@relay3.apple.com> Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Mon, 2 Aug 2004 12:55:21 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "John Schnizlein" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: DHCP discussion list 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >"Ongoing conflict detection and defense" appears an unnecessary >overhead unless hosts make up addresses rather than relying on >a simple allocator such as DHCP to assign them. It would have >been easy enough to define an initial election mechanism for >which host on a subnet, lacking a DHCP server, should provide >simple address allocation. The result would be a tiny amount >of extra work for one host instead of all the "ongoing conflict >detection and defense" for all hosts. I really don't know what overhead you're talking about. There are no extra packets to do ongoing conflict detection (and no change to existing packets). If you mean CPU overhead, there really isn't any, because this is just a tiny refinement to the existing code path for handling received ARP packets. All the draft says is that if you see someone else broadcast an ARP packet, and when you go to update your ARP cache you find that it's YOUR OWN IP address that you're about to update to point to some other machine's hardware address, that's bad news, and you probably shouldn't ignore it. That's all: When you observe that the network is broken, then you should at least alert the user in some way so that they have an idea what is wrong. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 18:55:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12359; Mon, 2 Aug 2004 18:55:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brjhv-0004VZ-H8; Mon, 02 Aug 2004 16:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brjay-0001tM-3X for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 16:39:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04115 for ; Mon, 2 Aug 2004 16:39:42 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brjdt-00046K-1D for dhcwg@ietf.org; Mon, 02 Aug 2004 16:42:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2004 13:40:34 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i72Kd8Q2018626; Mon, 2 Aug 2004 13:39:08 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([10.82.217.0]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO08550; Mon, 2 Aug 2004 16:39:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040802163557.02b10d80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Aug 2004 16:39:04 -0400 To: Stuart Cheshire From: Ralph Droms Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft In-Reply-To: <200408021949.i72JnCQg004282@relay4.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: DHCP discussion list , babatke@ra.rockwell.com, Ted Lemon 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At 12:49 PM 8/2/2004 -0700, Stuart Cheshire wrote: >The question of whether to announce via ARP request or response is >something that really doesn't matter, and is therefore the thing >guaranteed to generate the greatest amount of debate. As John Schnizlein >correctly pointed out, "RFC 826 explicitly does not discriminate between >request or reply messages before updating its table". If it really doesn't matter, why are we having this discussion? Are you proposing we change DHCP to use an ARP request for announcements? >Here's what I plan to put in the next draft: > >Why are ARP Announcements performed using ARP Request packets and not >ARP Reply packets? > >There are two reasons, one is historical precedent, and the other is >practicality. > >The historical precedent is that Gratuitous ARP is described in Stevens >Networking [Ste94] as using ARP Request packets. It would be better to cite an historical precedent from an RFC. I seem to remember (I looked it up once before but am in the airport without access to reference materials) that Comer describes gratuitous ARP as using an ARP Reply message. >The practical reason is that ARP Request packets are more likely to work >correctly with more existing ARP implementations, some of which may not >implement RFC 826 correctly. Do you have specific examples of stacks that work when an ARP Request is received but not when an ARP Reply is received? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 21:58:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21807; Mon, 2 Aug 2004 21:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroVq-0007Pv-OM; Mon, 02 Aug 2004 21:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroU0-0006ys-RE for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 21:52:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21645 for ; Mon, 2 Aug 2004 21:52:51 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BroWz-0000hi-87 for dhcwg@ietf.org; Mon, 02 Aug 2004 21:55:57 -0400 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:5932:46d5:8557:40fa]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F17BE1525D; Tue, 3 Aug 2004 10:52:42 +0900 (JST) Date: Tue, 03 Aug 2004 10:52:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: venaas@uninett.no, tjc@ecs.soton.ac.uk User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dhcwg@ietf.org Subject: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hoping it's not too late, here a couple of comments (or questions, actually) on the draft. 1. I'm still not really sure what the client should do for information when a lifetime expires. For example, the draft says in Section 3.1 that If client has received a lifetime with this option, and contacts server to receive new or update any existing data prior to its expiration, it SHOULD also update data covered by this option. If no new lifetime is received, it MUST behave as if no value was ever provided. I don't understand the scenario. Does this mean the following case? - The client sends an Information-request message, and gets a reply with a DNS server address (call it X) with lifetime of 1 hour. - 30 minutes later, the client happens to resend an Information-request message. This time, it gets a response, but the response does not contain either DNS server address X or a new lifetime. If this is an intended scenario, then what does "behave as if no value was ever provided"? Does it mean the client MUST treat address X as if it had infinite lifetime? Or does this mean the client MUST regard address X expired immediately? Or something else? Also, I don't understand what the client should do with DNS server address X when the lifetime expires and the client does not get any reply for the try to update the information. Should the client invalidate address X? Can/should it continue to use it? Even if the client can update the information of address X with a new lifetime, how can we regard the period from the time when the previous lifetime expires and the time when the client gets the new information? Should we temporarily invalidate the address during the update period? Or Can we continue to use it? Probably the latter makes sense when the client can update the information, but it does not really match my intuition of "expiration"... 2. the usage of the lifetime option for other exchanges than Info-req/Reply exchanges. I'm even not 100% sure if the lifetime can be used for the other types of exchanges. Probably it can according to the draft, but then I'll have several questions on how to use it. For example, the draft says: Before making the request it MUST wait for a random amount of time between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. Is this also applies to the other cases even if INF_MAX_DELAY is a dedicated parameter for Info-req? If so, is it really valid? Also, how does the client exactly react to the expiration event for the other cases? For example, consider the following scenario: - the client performs Solicit->Advertise->Request->Reply exchanges, and gets an IPv6 address allocated, a DNS server address X, and an associated lifetime T. - before the timeout "T1" for the allocated address passes, lifetime T expires. In this case, should the client restart the entire session from Solicit? Or should the client send a renew message? If so, the renew message also tries to update the allocated address even if it's too early? Or should the client even start Information-request/Reply exchanges just to update the DNS address information? As an implementor, it's very hard to implement this option with confidence just from this specification... 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 Aug 2 23:44:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26938; Mon, 2 Aug 2004 23:44:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrqAb-0003R2-JJ; Mon, 02 Aug 2004 23:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brq4Y-0008L5-FJ for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 23:34:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26328 for ; Mon, 2 Aug 2004 23:34:40 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brq7W-0001wJ-Jc for dhcwg@ietf.org; Mon, 02 Aug 2004 23:37:48 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i733XwV0016523; Tue, 3 Aug 2004 05:33:58 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i733XvvE020604; Tue, 3 Aug 2004 05:33:57 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 3 Aug 2004 05:33:57 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040803033357.GA20506@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk Subject: [dhcwg] Re: comments on draft-ietf-dhc-lifetime-01.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 03, 2004 at 10:52:42AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > Hoping it's not too late, here a couple of comments (or questions, > actually) on the draft. > > 1. I'm still not really sure what the client should do for information > when a lifetime expires. > > For example, the draft says in Section 3.1 that > > If client has received a lifetime with this option, and contacts > server to receive new or update any existing data prior to its > expiration, it SHOULD also update data covered by this option. If no > new lifetime is received, it MUST behave as if no value was ever > provided. > > I don't understand the scenario. Does this mean the following case? > > - The client sends an Information-request message, and gets a reply > with a DNS server address (call it X) with lifetime of 1 hour. > - 30 minutes later, the client happens to resend an > Information-request message. This time, it gets a response, but > the response does not contain either DNS server address X or a new > lifetime. > > If this is an intended scenario, then what does "behave as if no > value was ever provided"? Does it mean the client MUST treat > address X as if it had infinite lifetime? Or does this mean the > client MUST regard address X expired immediately? Or something > else? I'm open for anything. But my intention is that client behaves as if it didn't get a lifetime in the first place. That is, just like it would behave if it doesn't know a specific lifetime. Whether it's infinite or not, depends on the client. I don't think this scenario will be common anyway, but we should say something. My thinking is that the last response is the authoritative one, so new lifetime value overrides the old, and no lifetime means ignore the old and behave like you haven't ever seen one. Another option would be to keep using the last seen lifetime until expiry, but I'm not sure that's better. Very happy to see suggestions for alternative behaviour, or for text changes that makes it more clear. > Also, I don't understand what the client should do with DNS server > address X when the lifetime expires and the client does not get any > reply for the try to update the information. Should the client > invalidate address X? Can/should it continue to use it? I think it can be left to the client. The client will retry for a long period of time, and would usually get updated info; the lifetime simply says when to start this process. So you're talking about a rare failure case. I think it's sensible to keep using the info, at least if there is nothing to fall back to. I'm thinking of the option as a hint to the client when it should try to update the info. I'm not sure if we need to specify the failure modes in detail. > Even if the client can update the information of address X with a > new lifetime, how can we regard the period from the time when the > previous lifetime expires and the time when the client gets the new > information? Should we temporarily invalidate the address during > the update period? Or Can we continue to use it? Probably the > latter makes sense when the client can update the information, but > it does not really match my intuition of "expiration"... My intention is definitely that you should continue using it. I guess that should be made clear. > 2. the usage of the lifetime option for other exchanges than > Info-req/Reply exchanges. > > I'm even not 100% sure if the lifetime can be used for the other > types of exchanges. Probably it can according to the draft, but > then I'll have several questions on how to use it. > > For example, the draft says: > > Before making the request it MUST wait for a random amount of time > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. > > Is this also applies to the other cases even if INF_MAX_DELAY is a > dedicated parameter for Info-req? If so, is it really valid? > > Also, how does the client exactly react to the expiration event for > the other cases? For example, consider the following scenario: > > - the client performs Solicit->Advertise->Request->Reply exchanges, > and gets an IPv6 address allocated, a DNS server address X, and an > associated lifetime T. > - before the timeout "T1" for the allocated address passes, lifetime > T expires. In this case, should the client restart the entire > session from Solicit? Or should the client send a renew message? > If so, the renew message also tries to update the allocated > address even if it's too early? Or should the client even start > Information-request/Reply exchanges just to update the DNS address > information? I agree, this needs more thought. So first question is whether we should support stateless only. Stateless is what I'm focusing on, but when I wrote it I thought it could also be of use for stateful case. As it says, the option only specifies a lifetime for options that don't have an associated lifetime. I think doing Information-request/Reply exchange just to update the DNS address information is fine, but would it be a problem to renew everything? > As an implementor, it's very hard to implement this option with > confidence just from this specification... Right. I think this is very good input. I would like to get more input on which behaviour people think is best. Then I'll try to make the text clearer. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:42:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03245; Tue, 3 Aug 2004 01:42:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryV-0007UR-6s; Tue, 03 Aug 2004 01:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwK-0006IJ-4w for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02899 for ; Tue, 3 Aug 2004 01:34:19 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrrzJ-0003hS-O3 for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:27 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2004 22:35:14 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xh78013603; Mon, 2 Aug 2004 22:33:43 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31694; Tue, 3 Aug 2004 01:33:38 -0400 (EDT) From: "Bernie Volz" To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?= , "'Christian Strauf'" Subject: RE: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000001c4791b$6e25deb0$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Personally, I wouldn't call a message that has failed validation to be "unauthenticated". 21.4.2 is pretty clear that these messages should be discarded. You really have three types of messages: - Authenticated - those that passed the validation and have meaning authentication data in them. - Failed validation - those that failed validation, because of replay detection, MAC validation, etc. - Unauthenticated - those that either had no authentication option or = had incomplete authentication information (such as in a client's SOLICIT). = But, read on. Neither clients nor servers would ever want to process "failed = validation" messages. However, they better process the other two. Now, I believe, but could be wrong, that the intent of section 21.4.4.2 = in RFC 3315 (your section 5 of the draft) was that a client could well = receive a message which it can not validate because it doesn't have the required security association information or doesn't support the authentication protocol. This is very different from when it does have this information = and finds that a message does not validate. So, perhaps the "Unauthenticated" category needs another condition - if = the client or server is unable to validate a message because it lacks the = key (for the realm/server) or doesn't support the authentication protocol. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of JINMEI Tatuya / =90_=96=BE=92B=8D=C6 > Sent: Monday, July 26, 2004 3:59 AM > To: Christian Strauf > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Comments on=20 > draft-jinmei-dhc-dhcpv6-clarify-auth-00 >=20 >=20 > Hello, >=20 > Thanks for your positive feedback, and sorry for the delayed response. >=20 > >>>>> On Tue, 20 Jul 2004 16:23:41 +0200, > >>>>> Christian Strauf said: >=20 > > I paragraph 4. you write: >=20 > > "A reasonable interpretation of the phrase is probably as > follows: a > > DHCPv6 message is called unauthenticated when it fails the > validation > > test described in Section 21.4.2, it does not contain an > > authentication option, or when it includes an authentication option=20 > > but does not have authentication information when necessary." >=20 > > I would propose a minor rephrasing to clear the language up > a little > > (if I understand the above paragraph correctly, the following > > rewording should work): >=20 > > "A reasonable interpretation of the phrase is as follows: a DHCPv6 > > message is called unauthenticated if it fails the validation test=20 > > described in Section 21.4.2, if it does not contain an=20 > authentication > > option, or if it includes an authentication option without the > > necessary authentication information." >=20 > OK. I've modified the local source of the draft with the > suggested change. >=20 > > Minor typos: >=20 > > para 2.: > > -It should also be noted that [RFC3315] does not define how the > > server should do when it receives > > +It should also be noted that [RFC3315] does not > define what the > > server should do when it receives >=20 > > para 3.: > > -3. What If Reply Is Detected > > +3. What If Replay Is Detected >=20 > > para 5.: > > -Apparently this contradicts with the requirement in Section > > 21.4.2. > > +Apparently this contradicts the requirement in Section 21.4.2. >=20 > > para 5.1.: > > -Accepting an non-authenticated > > +Accepting a non-authenticated >=20 > Thanks, fixed in the local source. (The second and fourth > typos should already be fixed in the published version of the=20 > draft. I guess your comments are for a preliminary version=20 > available at my web > page.) >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Tue Aug 3 01:43:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03352; Tue, 3 Aug 2004 01:43:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryV-0007Ua-JC; Tue, 03 Aug 2004 01:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwQ-0006IN-S3 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02908 for ; Tue, 3 Aug 2004 01:34:26 -0400 (EDT) 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.33) id 1BrrzQ-0003hr-Hp for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Aug 2004 22:36:08 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xo78013736; Mon, 2 Aug 2004 22:33:51 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31695; Tue, 3 Aug 2004 01:33:40 -0400 (EDT) From: "Bernie Volz" To: , , Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000101c4791b$739a81c0$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: "'DHC WG \(E-mail\)'" Subject: [dhcwg] RE: draft-jang-dhc-haopt-00.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi. In preparing for the DHC WG meeting I have the following comments on draft-jang-dhc-haopt-00.txt: In DHCPv6 we use 16-bit option (and suboption) codes and lengths. It = would be best if this draft switched to using 16-bit fields for the sub-option = and length fields. Please see RFC 3315 and section 22.17. Note also that for some forms of identification/authentication (opaque type), it is = conceivable that it might exceed a length of 255 bytes! Also, with a 16-bit option number space, we've got plenty of option = number space and it might be best to drop the Home Agent Discovery Option and simply make the two sub-options regular options? Or, is there a reason = you'd prefer having sub-options? For the Home Network Information Sub-option, I assume that if multiple addresses (or prefixes) are specified, the A, reserved, prefix-length = and address/prefix fields are all repeated (18 bytes/address). It might be = good to specify this? - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:44:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03468; Tue, 3 Aug 2004 01:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryV-0007Uf-T4; Tue, 03 Aug 2004 01:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwT-0006IP-0l for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02911 for ; Tue, 3 Aug 2004 01:34:28 -0400 (EDT) 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.33) id 1BrrzS-0003hr-OB for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Aug 2004 22:36:10 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xr78013774; Mon, 2 Aug 2004 22:33:54 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31700; Tue, 3 Aug 2004 01:33:50 -0400 (EDT) From: "Bernie Volz" To: Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000201c4791b$7567eec0$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: "'DHC WG \(E-mail\)'" , olnrao@samsung.com, syam@samsung.com Subject: [dhcwg] RE: draft-daniel-dhc-dhcpv4-tep-conf-01.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Daniel: While preparing for the IETF meeting, I have these comments on the draft-daniel-dhc-dhcpv4-tep-conf-01.txt draft. It's probably best to remove the "reserved" byte from the two options in this draft unless you expect to use this field sometime in the future. Trying to align the remaining fields is really useless since there is no guarentee that the option byte will be aligned on any particular boundry (other than on a byte boundry). The client and server will just have to pack/unpack the data. And, saving the one byte from the option could be useful (as DHCPv4 is often restricted to fairly small packet sizes). And, it might be best to move the prefix-length field to before the IPv6 address (keeping them together).=20 The DHCP messages used in this draft are the DHCPv6 ones - not the = DHCPv4 ones. You really want to use DHCPDISCOVER, DHCPOFFER, DHCPACK and the = like for the message names! I also don't understand the need for the OPTION_CTEP_REQ option. Either = you need to explain this better in the draft (what, for example would the = client fill in in this option) or remove it - why can't the client just simply request this option in a Parameter Request List option? - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:47:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03680; Tue, 3 Aug 2004 01:47:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryW-0007Uz-Ln; Tue, 03 Aug 2004 01:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwT-0006IR-LA for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02914 for ; Tue, 3 Aug 2004 01:34:29 -0400 (EDT) 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.33) id 1BrrzT-0003hz-8Z for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Aug 2004 22:36:14 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xv78013817; Mon, 2 Aug 2004 22:33:57 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31703; Tue, 3 Aug 2004 01:33:54 -0400 (EDT) From: "Bernie Volz" To: , , Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000401c4791b$77efd220$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "'DHC WG \(E-mail\)'" Subject: [dhcwg] RE: draft-chowdhury-dhc-bcmcv4-option-00.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit While preparing for the DHC WG meeting, I found these issues with draft-chowdhury-dhc-bcmcv4-option-00.txt: Option-Request-Option is used when it should be Parameter Request List option. In section 2, informative is misspelled (inforamtive). Client is misspelled (as cleint). It is likely a bad idea to specify DNS compression. But this may be something best discussed during the WG meeting or on the mailing list. With the current design, it is only possible for ONE type of encoding to be used (since multiple instances of the option are concatenated). So, you might consider moving the encoding byte before EVERY entry in the list. So, one could have: <0><1><0>domain-name> Section 5 says "DHCPv6" when it should say DHCPv4. A reference in this security issues section to RFC 3118 might also be appropriate? See some of the other existing drafts for what you might add? You might word the IANA Consideration section as: IANA is requested to assign a DHCPv4 option code for the Broadcast Service Controller Domain Name list option, in accordance with RFC 2939. I'm also wondering whether IANA needs to maintain a list of the encoding types? But, hopefully not. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:48:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03761; Tue, 3 Aug 2004 01:48:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryX-0007Vo-1q; Tue, 03 Aug 2004 01:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwV-0006IY-Hp for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02917 for ; Tue, 3 Aug 2004 01:34:30 -0400 (EDT) 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.33) id 1BrrzV-0003i1-7p for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Aug 2004 22:34:39 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xt78013789; Mon, 2 Aug 2004 22:33:55 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31701; Tue, 3 Aug 2004 01:33:52 -0400 (EDT) From: "Bernie Volz" To: , , Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000301c4791b$76cf1fe0$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "'DHC WG \(E-mail\)'" Subject: [dhcwg] RE: draft-chowdhury-dhc-bcmcv4-option-00.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit While preparing for the DHC WG meeting, I found these issues with draft-chowdhury-dhc-bcmcv6-option-00.txt: As DHCPv6 doesn't support broadcasting, you're really only able to support multicasting. Not sure if this should be pointed out early in the draft? And, perhaps the option (in the DHCPv6 case) should not use "broadcast" in its name? RFC 3315, section 8, specifically prohibits compression. You should follow that rule. Informative is misspelling in this document as well (inforamtive). - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 02:00:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04499; Tue, 3 Aug 2004 02:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrsFd-0006DA-7F; Tue, 03 Aug 2004 01:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brs5o-0002C5-BY for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:44:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03432 for ; Tue, 3 Aug 2004 01:44:07 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brs8n-0003qX-R5 for dhcwg@ietf.org; Tue, 03 Aug 2004 01:47:15 -0400 Received: from [66.93.162.248] (0127bhost249.starwoodbroadband.com [12.105.247.249]) by toccata.fugue.com (Postfix) with ESMTP id A10C91B29C3; Tue, 3 Aug 2004 00:42:46 -0500 (CDT) In-Reply-To: <20040803033357.GA20506@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Re: comments on draft-ietf-dhc-lifetime-01.txt Date: Mon, 2 Aug 2004 22:43:07 -0700 To: Stig Venaas X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I think that we should specify what a client should do when it isn't given a lifetime option, rather than leaving it to the implementor. I would pick a number - say an hour - and recommend that as a default value when no lifetime has been given. I would require that this be configurable on the client. We should make sure that there isn't some corner case where a network administrator that wants a really long lifetime doesn't get hosed by the default value, but I don't think it's okay to just leave it unstated. Sorry for not saying this sooner - I was dithering over whether to make a point of it, and when Jinmei Tatuya stepped in with his observations, that gave me a good excuse to kibbitz. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 02:14:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17391; Tue, 3 Aug 2004 02:14:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrsRL-0004fP-0z; Tue, 03 Aug 2004 02:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrsKx-0007tX-9P for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04170 for ; Tue, 3 Aug 2004 01:59:46 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrsNt-00046w-Mh for dhcwg@ietf.org; Tue, 03 Aug 2004 02:02:54 -0400 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:85e5:b60e:c1e:7e67]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BFDF71525D; Tue, 3 Aug 2004 14:59:37 +0900 (JST) Date: Tue, 03 Aug 2004 14:59:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 In-Reply-To: <000001c4791b$6e25deb0$3e858182@amer.cisco.com> References: <000001c4791b$6e25deb0$3e858182@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 3 Aug 2004 01:33:37 -0400, >>>>> "Bernie Volz" said: > Personally, I wouldn't call a message that has failed validation to be > "unauthenticated". 21.4.2 is pretty clear that these messages should be > discarded. Yes. I think the main problem is in Section 21.4.4.2. > You really have three types of messages: > - Authenticated - those that passed the validation and have meaning > authentication data in them. > - Failed validation - those that failed validation, because of replay > detection, MAC validation, etc. > - Unauthenticated - those that either had no authentication option or had > incomplete authentication information (such as in a client's SOLICIT). But, > read on. > Neither clients nor servers would ever want to process "failed validation" > messages. However, they better process the other two. > Now, I believe, but could be wrong, that the intent of section 21.4.4.2 in > RFC 3315 (your section 5 of the draft) was that a client could well receive > a message which it can not validate because it doesn't have the required > security association information or doesn't support the authentication > protocol. This is very different from when it does have this information and > finds that a message does not validate. I think I agree with you on this (I believe this is essentially the same as the resolution I suggested in my draft). I guess it's basically an editorial issue, not a serious protocol problem. Here is the RFC's text (from section 21.4.4.2): Client behavior, if no Advertise messages include authentication information or pass the validation test, is controlled by local policy on the client. According to client policy, the client MAY choose to respond to an Advertise message that has not been authenticated. The first sentence indicates: if all Advertise messages are "Failed validation (from your categorization)" messages, client behavior is controlled by local policy on the client. so far, there's nothing odd. But the next sentence is ambiguous on the meaning of "message that has not been authenticated". Natural interpretation in this context should however be "messages that do not include authentication information or pass the validation test", i.e., "Failed validation" or "Unauthenticated" messages in your categorization. From this interpretation, the client MAY accept a "Failed validation" Advertise message, conflicting with the sense of Section 21.4.2. Section 21.4.4.2 then continues to the next paragraph: The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated Advertise message can make the client vulnerable to spoofing and other attacks. [...] Now, we see another unclear wording "unauthenticated messages" (see section 4 of my draft). Again, in this context, the natural interpretation should be as follows: "messages that do not include authentication information or pass the validation test" (2nd paragraph of 21.4.4.2) = "message that has not been authenticated" (2nd paragraph of 21.4.4.2) = "unauthenticated messages" (3rd paragraph of 21.4.4.2) = "Failed validation" or "Unauthenticated" messages (from your definition) Then the result of this interpretation contradicts what is described in Section 21.4.2. Once we agree on that Section 21.4.2 should be honored, the resolution would be minor editorial clarification in Section 21.4.4.2. 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 Aug 3 09:39:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08362; Tue, 3 Aug 2004 09:39:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrzSU-000801-6u; Tue, 03 Aug 2004 09:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrzRL-0007ty-TW for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 09:34:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08108 for ; Tue, 3 Aug 2004 09:34:50 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrzUN-0001Xy-Ox for dhcwg@ietf.org; Tue, 03 Aug 2004 09:38:03 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i73DY6Fg007238; Tue, 3 Aug 2004 08:34:06 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i73DY5C19387; Tue, 3 Aug 2004 09:34:05 -0400 (EDT) From: Joe Quanaim To: JINMEI Tatuya / =?utf-8?q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89=09?=, venaas@uninett.no, tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Tue, 3 Aug 2004 09:33:29 -0400 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408030929.31655.jdq@lucent.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: [...] > 2. the usage of the lifetime option for other exchanges than > Info-req/Reply exchanges. > > I'm even not 100% sure if the lifetime can be used for the other > types of exchanges. Probably it can according to the draft, but > then I'll have several questions on how to use it. > > For example, the draft says: > > Before making the request it MUST wait for a random amount of time > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. > > Is this also applies to the other cases even if INF_MAX_DELAY is a > dedicated parameter for Info-req? If so, is it really valid? Isn't this duplicating rfc 3315? Removing it would prevent any subsequent= =20 updates to rfc 3315 from conflicing with this statement. > Also, how does the client exactly react to the expiration event for > the other cases? For example, consider the following scenario: > > - the client performs Solicit->Advertise->Request->Reply exchanges, > and gets an IPv6 address allocated, a DNS server address X, and an > associated lifetime T. > - before the timeout "T1" for the allocated address passes, lifetime > T expires. In this case, should the client restart the entire > session from Solicit? Or should the client send a renew message? > If so, the renew message also tries to update the allocated > address even if it's too early? Or should the client even start > Information-request/Reply exchanges just to update the DNS address > information? Using this option in a stateful transaction makes things more complicated. = =20 The lifetime option can expire between t1, t2, or the valid lifetime of an= =20 address. As Jinmei Tatuya notes, what should the client be expected to do?= =20 Restart the message exchange; just do an information-request; etc. Any negotiated value for t1, t2, or valid lifetime of an address could take= =20 precedence over the lifetime option. This essentially makes the option=20 stateless only, but it simplifies the resulting changes to a client=20 implementation. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 10:15:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11004; Tue, 3 Aug 2004 10:15:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs00X-0007Ye-Kd; Tue, 03 Aug 2004 10:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrzxH-0006CV-P7 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 10:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09979 for ; Tue, 3 Aug 2004 10:07:50 -0400 (EDT) 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.33) id 1Bs00M-0001xk-9B for dhcwg@ietf.org; Tue, 03 Aug 2004 10:11:03 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2004 07:08:04 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i73E717a021331 for ; Tue, 3 Aug 2004 07:07:17 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-255.cisco.com [10.82.224.255]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO47046; Tue, 3 Aug 2004 10:06:57 -0400 (EDT) Message-Id: <4.3.2.7.2.20040803100416.02062638@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 10:04:33 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [dhcwg] jabber during dhc WG meeting 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org For more information, go to http://xmpp.org/ietf-chat.html - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 11:26:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15404; Tue, 3 Aug 2004 11:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs17i-0007Uz-9N; Tue, 03 Aug 2004 11:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs163-0007OQ-6K for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 11:20:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15081 for ; Tue, 3 Aug 2004 11:20:56 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs197-00030R-TA for dhcwg@ietf.org; Tue, 03 Aug 2004 11:24:11 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id B5E871B22D6 for ; Tue, 3 Aug 2004 10:20:10 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: dhcwg@ietf.org From: Ted Lemon Date: Tue, 3 Aug 2004 08:20:53 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-chowdhury-dhc-bcmcv4-option 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Reading over this draft, a couple of things jump out at me. The first is that all the text describing how BCMCS works should probably be left out. I would put in a one-paragraph description of what BCMCS does. Putting in a big diagram and a detailed description doesn't help the implementor, and the description didn't actually tell me much about what the protocol does. The other things is, do you really need to send FQDNs? They take up a lot of space in a DHCP packet. I would rather see you send IPv4 address/port number tuples if you want to be able to specify the port. This would also eliminate the need to consume two option codes, which in DHCPv4 is theoretically an issue. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 11:36:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15977; Tue, 3 Aug 2004 11:36:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1GT-00081b-CL; Tue, 03 Aug 2004 11:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1Dl-0007tI-7p for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 11:28:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15636 for ; Tue, 3 Aug 2004 11:28:55 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs1Gq-00037c-Az for dhcwg@ietf.org; Tue, 03 Aug 2004 11:32:09 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i73FSGUO013246; Tue, 3 Aug 2004 17:28:17 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i73FSFl2026541; Tue, 3 Aug 2004 17:28:15 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 3 Aug 2004 17:28:15 +0200 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] Re: comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040803152815.GA26389@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 02, 2004 at 10:43:07PM -0700, Ted Lemon wrote: > I think that we should specify what a client should do when it isn't > given a lifetime option, rather than leaving it to the implementor. I > would pick a number - say an hour - and recommend that as a default > value when no lifetime has been given. I would require that this be > configurable on the client. We should make sure that there isn't some > corner case where a network administrator that wants a really long > lifetime doesn't get hosed by the default value, but I don't think it's > okay to just leave it unstated. First, if the option is implemented by both client and server, I would expect it to always be used. One hour sounds rather short to me, normally I would expect several days between each change. Question is then how bad it is if there is a change and it takes some time before the client learns of it. But why wouldn't you use this option if you worry about that. I would expect most servers to support this option... I think I would choose 6 hours or something as default, but that's just my personal feeling. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 11:55:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16913; Tue, 3 Aug 2004 11:55:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1T0-0000ke-9M; Tue, 03 Aug 2004 11:44:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1OV-0000I8-0T for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 11:40:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16177 for ; Tue, 3 Aug 2004 11:40:00 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs1RZ-0003HT-TE for dhcwg@ietf.org; Tue, 03 Aug 2004 11:43:15 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id 841EC1B221E for ; Tue, 3 Aug 2004 10:39:15 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) To: dhcwg@ietf.org Message-Id: <60325F40-E563-11D8-982E-000A95D9C74C@nominum.com> Content-Type: multipart/mixed; boundary=Apple-Mail-2--576234703 From: Ted Lemon Date: Tue, 3 Aug 2004 08:39:58 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [dhcwg] comments on draft-daniel-dhc-dhcpv4-tep-conf 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --Apple-Mail-2--576234703 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit This draft breaks a couple of existing assumptions about DHCP. First, it requires that the option be send only in a DHCPACK message in response to a DHCPREQUEST message. Normally the DHCPOFFER message contains the same options as the DHCPACK message. So I would strongly suggest that this restriction be relaxed to allow the DHCPOFFER to contain this option. Secondly, the draft allows multiple copies to appear. This contradicts the Encoding Long Options RFC (sorry, can't remember the number off the top of my head), which would create a huge headache for DHCP server and client implementations. So please change the option so that there can be only one of them, and that if multiple values need to be sent, that is encoded within the option. Also, there is quite a bit of information in this document that goes beyond describing the format of the option. It looks like you're defining a new protocol. If you are not defining a new protocol, it would be better to refer to the document that defines the protocol, and remove the words from this document that describe that protocol in detail. If you are defining a new protocol here, this draft probably needs to be reviewed by the working group responsible for that area as well as by the DHC working group. (sorry if this has already been said) I've enclosed a couple of diffs for some minor editorial suggestions. --Apple-Mail-2--576234703 Content-Type: application/octet-stream; x-unix-mode=0640; name="draft-daniel-dhc-dhcpv4-tep-conf-comments" Content-Disposition: attachment; filename=draft-daniel-dhc-dhcpv4-tep-conf-comments Content-Transfer-Encoding: 7bit *** draft-daniel-dhc-dhcpv4-tep-conf-01.txt Thu Jul 8 12:50:00 2004 --- draft-daniel-dhc-dhcpv4-tep-conf-01-hacked.txt Tue Aug 3 08:37:19 2004 *************** *** 42,48 **** The intent of this draft is to provide a solution to automate tunnel end-point configuration for a configured IPv6-over-IPv4 tunnel. This ! uses a DHCPv4 option to percolate the tunnel end-point configuration information. This is very useful to connect a newly deployed native IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6 --- 42,48 ---- The intent of this draft is to provide a solution to automate tunnel end-point configuration for a configured IPv6-over-IPv4 tunnel. This ! uses a DHCPv4 option to distribute the tunnel end-point configuration information. This is very useful to connect a newly deployed native IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6 *************** *** 68,81 **** such IPv6 networks or hosts without manual configuration. To configure IPv6-over-IPv4 tunnel between isolated IPv6 networks, ! administrator typically configure available tunnels by hand. That ! is, imagine that we want to connect 10 sites together from our border router using full-mesh configured tunneling. We will have to ! set up 9 tunnels in each site, 9*10 tunnels in total. Thus we need a solution to automate the process of building configured tunnels at border routers connected through IPv4 backbone. ! This introduces new DHCPv4 options to distribute the configuration tunnel information automatically. --- 68,82 ---- such IPv6 networks or hosts without manual configuration. To configure IPv6-over-IPv4 tunnel between isolated IPv6 networks, ! administrator typically configure available tunnels by hand. Con- ! sider the case where we want to connect 10 sites together from our border router using full-mesh configured tunneling. We will have to ! set up 9 tunnels in each site, 9*10 tunnels in total. To address ! cases like this we need a solution to automate the process of building configured tunnels at border routers connected through IPv4 backbone. ! This document introduces new DHCPv4 options to distribute the configuration tunnel information automatically. *************** *** 238,247 **** - Appearance of this option: The Configured Tunnel End Point Reply Option MUST NOT appear in any ! message other than the DHCPREPLY message in correspond to the Configured Tunnel End Point Request Option with DHCPREQUEST message. ! This option MAY appear multiple times in DHCPREPLY message. --- 239,248 ---- - Appearance of this option: The Configured Tunnel End Point Reply Option MUST NOT appear in any ! message other than the DHCPACK message that corresponds to the Configured Tunnel End Point Request Option with DHCPREQUEST message. ! This option MAY appear multiple times in DHCPACK message. --Apple-Mail-2--576234703 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-2--576234703-- From dhcwg-bounces@ietf.org Tue Aug 3 12:44:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20186; Tue, 3 Aug 2004 12:44:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2DS-0000JK-UO; Tue, 03 Aug 2004 12:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2Au-0008O6-Dx for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:30:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19258 for ; Tue, 3 Aug 2004 12:30:01 -0400 (EDT) Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2E0-0004CR-5Y for dhcwg@ietf.org; Tue, 03 Aug 2004 12:33:17 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i73GTUx01392; Tue, 3 Aug 2004 12:29:30 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 12:29:29 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE920218AE03@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Ted Lemon , dhcwg@ietf.org Subject: RE: [dhcwg] Comments on draft-chowdhury-dhc-bcmcv4-option Date: Tue, 3 Aug 2004 12:29:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ted, Thanks for your comment/suggestion. We added the informative diagram to at least give the reader some idea what B-cast and M-cast service typically include. If you think a simplified diagram will suffice we can do that in the next revision. FQDN is used to give the operator flexibility in deploying the service. Some operators would like to use DNS infrastructure to distribute the most appropriate controller for a broadcast program. Regards, Kuntal >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >On Behalf Of Ted Lemon >Sent: Tuesday, August 03, 2004 10:21 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Comments on draft-chowdhury-dhc-bcmcv4-option > > >Reading over this draft, a couple of things jump out at me. >The first >is that all the text describing how BCMCS works should >probably be left >out. I would put in a one-paragraph description of what >BCMCS does. >Putting in a big diagram and a detailed description doesn't help the >implementor, and the description didn't actually tell me much about >what the protocol does. > >The other things is, do you really need to send FQDNs? They >take up a >lot of space in a DHCP packet. I would rather see you send IPv4 >address/port number tuples if you want to be able to specify >the port. > This would also eliminate the need to consume two option >codes, which >in DHCPv4 is theoretically an issue. > > >_______________________________________________ >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 Tue Aug 3 13:12:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22652; Tue, 3 Aug 2004 13:12:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2j9-00054w-5t; Tue, 03 Aug 2004 13:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2U6-0002kL-Ig for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:49:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20649 for ; Tue, 3 Aug 2004 12:49:52 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2XA-0004Zw-Qj for dhcwg@ietf.org; Tue, 03 Aug 2004 12:53:07 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id 7B1571B225B for ; Tue, 3 Aug 2004 11:49:03 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <7C7FE7F6-E565-11D8-982E-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: dhcwg@ietf.org From: Ted Lemon Date: Tue, 3 Aug 2004 08:55:05 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comment on a couple of option drafts that have gone by... 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I've noticed that a couple of drafts have gone by that require the client to send an option to the server so that the server will know what to send back to the client. In each of these cases, this seems like a reasonable way to solve the problem. However, I would like to point out one problem with this, and request that the authors of these drafts (I'm thinking specifically of the haopt and tep drafts) add some text to talk about what the client should send in the parameter request list. Currently the FQDN option protocol specification requires the server to send back an FQDN option even if the client sends a parameter request list and doesn't include the FQDN option code in that list. Please specify in your drafts that the DHCP server must not send the reply option unless either no parameter request list is sent, or unless the option code for the option appears in the parameter request list. Suggested text: The DHCP server MUST NOT send the Foo option if the client sends a Parameter Request List option and the code for the Foo option does not appear in the parameter request list, EVEN IF the Foo-request option appears in the client's list of options. The reason for making this request is that we have to have special case code in the DHCP server to make sure the FQDN option gets sent even if not requested, and this adds needless complexity. If you add text like what I've suggested above, you are not placing this requirement on the server - the server can just process the option normally when constructing the reply. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 13:12:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22725; Tue, 3 Aug 2004 13:12:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2j9-00055H-IP; Tue, 03 Aug 2004 13:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2U7-0002kH-KV for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:49:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20646 for ; Tue, 3 Aug 2004 12:49:51 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2XB-0004Zy-K9 for dhcwg@ietf.org; Tue, 03 Aug 2004 12:53:07 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id AB0981B2298; Tue, 3 Aug 2004 11:49:03 -0500 (CDT) In-Reply-To: <200408030929.31655.jdq@lucent.com> References: <200408030929.31655.jdq@lucent.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1FCC835A-E56D-11D8-982E-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Tue, 3 Aug 2004 09:49:45 -0700 To: jdq@lucent.com X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit IMHO, this draft should be folded into any future update of RFC3315. So it's okay to contradict 3315 if that is the correct thing to, although we shouldn't do it gratuitously. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 13:14:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22849; Tue, 3 Aug 2004 13:14:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2jB-00056h-6K; Tue, 03 Aug 2004 13:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2WY-0002yZ-Q7 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20921 for ; Tue, 3 Aug 2004 12:52:24 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2Ze-0004cw-J9 for dhcwg@ietf.org; Tue, 03 Aug 2004 12:55:39 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id 73E7C1B20C2; Tue, 3 Aug 2004 11:51:38 -0500 (CDT) In-Reply-To: <591B780D9676844E8A704B5B013FFE920218AE03@zrc2hxm1.corp.nortel.com> References: <591B780D9676844E8A704B5B013FFE920218AE03@zrc2hxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7D34752F-E56D-11D8-982E-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-chowdhury-dhc-bcmcv4-option Date: Tue, 3 Aug 2004 09:52:22 -0700 To: "Kuntal Chowdhury" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 9:29 AM, Kuntal Chowdhury wrote: > FQDN is used to give the operator flexibility in deploying the > service. Some > operators would like to use DNS infrastructure to distribute the most > appropriate controller for a broadcast program. If you fill up the DHCP packet, the operator loses that flexibility. An easy way to provide the same flexibility is to do the lookup on the DHCP server. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 13:21:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23446; Tue, 3 Aug 2004 13:21:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2lZ-0005cX-AI; Tue, 03 Aug 2004 13:07:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2gv-0004lJ-Kq for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:03:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21963 for ; Tue, 3 Aug 2004 13:03:06 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2k1-0004uB-JT for dhcwg@ietf.org; Tue, 03 Aug 2004 13:06:22 -0400 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:53:a078:f69:a107]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 56C9B1525D; Wed, 4 Aug 2004 02:03:02 +0900 (JST) Date: Wed, 04 Aug 2004 02:03:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig.Venaas@uninett.no, tjc@ecs.soton.ac.uk User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: dhcwg@ietf.org Subject: [dhcwg] one more comment about the lifetime option 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I forgot to mention this one: Is it possible to specify different lifetimes for different instances of stateless information? For example, people may want to specify different lifetimes for recursive DNS server addresses and for SIP server addresses. 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 Aug 3 13:47:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26108; Tue, 3 Aug 2004 13:47:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2zI-0008T3-S0; Tue, 03 Aug 2004 13:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2sr-00072W-By for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:15:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22970 for ; Tue, 3 Aug 2004 13:15:26 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2vw-00059X-D2 for dhcwg@ietf.org; Tue, 03 Aug 2004 13:18:42 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i73HEmUO002014; Tue, 3 Aug 2004 19:14:48 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i73HElX6027873; Tue, 3 Aug 2004 19:14:47 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 3 Aug 2004 19:14:47 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040803171447.GA27805@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk Subject: [dhcwg] Re: one more comment about the lifetime option 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, Aug 04, 2004 at 02:03:04AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > I forgot to mention this one: > > Is it possible to specify different lifetimes for different instances > of stateless information? For example, people may want to specify > different lifetimes for recursive DNS server addresses and for SIP > server addresses. We should keep this simple. If e.g. recursive server data needs to be updated more frequently than SIP data, I would simply say that lifetime should be the shortest. When you contact server to update DNS data, you can at the same time update other data like SIP server address. Note that the draft says: If client has received a lifetime with this option, and contacts server to receive new or update any existing data prior to its expiration, it SHOULD also update data covered by this option. If no new lifetime is received, it MUST behave as if no value was ever provided. In line with that SHOULD, there's no good reason to have multiple lifetimes. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 13:48:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26301; Tue, 3 Aug 2004 13:48:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs328-0000Ja-07; Tue, 03 Aug 2004 13:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2wq-0007hT-Ja for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23271 for ; Tue, 3 Aug 2004 13:19:33 -0400 (EDT) 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.33) id 1Bs2zx-0005Ep-O4 for dhcwg@ietf.org; Tue, 03 Aug 2004 13:22:50 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2004 10:19:52 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i73HIxme013870; Tue, 3 Aug 2004 10:18:59 -0700 (PDT) Received: from volzw2k (ams-clip-vpn-dhcp4106.cisco.com [10.61.80.9]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO64338; Tue, 3 Aug 2004 13:18:54 -0400 (EDT) From: "Bernie Volz" To: , "'JINMEI Tatuya / ???? '" , , Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Tue, 3 Aug 2004 13:20:22 -0400 Organization: Cisco Message-ID: <000201c4797e$2a5f37e0$46828182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <200408030929.31655.jdq@lucent.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I too would recommend that this option only be used with stateless (Information-Request/Reply). It does not apply to stateful - in stateful, even if there are no T1/T2 times (i.e., no IA_NA option), the client will need to do something when it no longer has addresses so it will get new information from the server. When the lifetime expires, the client should simply initiate an Information-Request message to the server(s). It should retry this 'forever' based on the Information-Request retransmission policy specified in RFC 3315 (see 18.1.5). When a (valid) REPLY is received, the client should remove its existing information and install the new information. If it doesn't receive a (valid) REPLY, it keeps its existing information. I too would support a default lifetime if no lifetime option is received. 6 to 12 hours seems a more reasonable value to me than 1 hour. Note also that I believe the lifetime is just one input ... The DHCP client can use other information, such as expiration of prefixes for configured items, to decide whether to refresh information (though this would require the DHCP client to poll the system periodically or when certain events occur which may or may not be practical). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Joe Quanaim > Sent: Tuesday, August 03, 2004 9:33 AM > To: JINMEI Tatuya / ???? ; venaas@uninett.no; tjc@ecs.soton.ac.uk > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt > > > > JINMEI Tatuya / $B?@L@C#:H(B wrote: > [...] > > 2. the usage of the lifetime option for other exchanges than > > Info-req/Reply exchanges. > > > > I'm even not 100% sure if the lifetime can be used for the other > > types of exchanges. Probably it can according to the draft, but > > then I'll have several questions on how to use it. > > > > For example, the draft says: > > > > Before making the request it MUST wait for a random > amount of time > > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC > > 3315]. > > > > Is this also applies to the other cases even if INF_MAX_DELAY is a > > dedicated parameter for Info-req? If so, is it really valid? > > Isn't this duplicating rfc 3315? Removing it would prevent > any subsequent > updates to rfc 3315 from conflicing with this statement. > > > Also, how does the client exactly react to the expiration > event for > > the other cases? For example, consider the following scenario: > > > > - the client performs Solicit->Advertise->Request->Reply > exchanges, > > and gets an IPv6 address allocated, a DNS server > address X, and an > > associated lifetime T. > > - before the timeout "T1" for the allocated address > passes, lifetime > > T expires. In this case, should the client restart the entire > > session from Solicit? Or should the client send a > renew message? > > If so, the renew message also tries to update the allocated > > address even if it's too early? Or should the client even start > > Information-request/Reply exchanges just to update the > DNS address > > information? > > Using this option in a stateful transaction makes things more > complicated. > The lifetime option can expire between t1, t2, or the valid > lifetime of an > address. As Jinmei Tatuya notes, what should the client be > expected to do? > Restart the message exchange; just do an information-request; etc. > > Any negotiated value for t1, t2, or valid lifetime of an > address could take > precedence over the lifetime option. This essentially makes > the option > stateless only, but it simplifies the resulting changes to a client > implementation. > > Joe Quanaim. > > > _______________________________________________ > 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 Tue Aug 3 14:27:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29544; Tue, 3 Aug 2004 14:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3p9-0002on-7q; Tue, 03 Aug 2004 14:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3Xc-0007FY-4C for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:57:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27049 for ; Tue, 3 Aug 2004 13:57:35 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3ai-0006GT-03 for dhcwg@ietf.org; Tue, 03 Aug 2004 14:00:49 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i73Hv2UO010853 for ; Tue, 3 Aug 2004 19:57:02 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i73Hv2Gk028380 for dhcwg@ietf.org; Tue, 3 Aug 2004 19:57:02 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 3 Aug 2004 19:57:02 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20040803175702.GA28332@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [dhcwg] How does DHCP client know when it's at home? 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Regarding the MIPv6 HA option, it was suggested that client would use this when at home, and ignore the option if it gets something when not at home. I don't understand how a client can know when it's at home, are there any mechanisms for that? If it is, it might be more useful to also have DHCP options for things like POP/IMAP servers etc where you want to learn the addresses when at home, and keep using the same when away. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 14:28:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29669; Tue, 3 Aug 2004 14:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3p9-0002os-JJ; Tue, 03 Aug 2004 14:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3Zp-0007fe-HI for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27298 for ; Tue, 3 Aug 2004 13:59:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3cw-0006Lr-1d for dhcwg@ietf.org; Tue, 03 Aug 2004 14:03:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2004 13:59:21 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i73HxERW016513; Tue, 3 Aug 2004 13:59:14 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-28.cisco.com [10.86.242.28]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO68233; Tue, 3 Aug 2004 13:59:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 13:59:10 -0400 To: "JINMEI Tatuya / ?$B?@L@C#:H" From: Ralph Droms Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: <20040803171447.GA27805@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I agree with Stig - we've discussed this issue before and come to the conclusion that there is little extra overhead in delivering information that has not changed, so there should be a single lifetime - chosen to be the shortest lifetome of any of the client's parameters. - Ralph At 07:14 PM 8/3/2004 +0200, Stig Venaas wrote: >On Wed, Aug 04, 2004 at 02:03:04AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > I forgot to mention this one: > > > > Is it possible to specify different lifetimes for different instances > > of stateless information? For example, people may want to specify > > different lifetimes for recursive DNS server addresses and for SIP > > server addresses. > >We should keep this simple. If e.g. recursive server data needs to be >updated more frequently than SIP data, I would simply say that lifetime >should be the shortest. When you contact server to update DNS data, you >can at the same time update other data like SIP server address. > >Note that the draft says: > > If client has received a lifetime with this option, and contacts > server to receive new or update any existing data prior to its > expiration, it SHOULD also update data covered by this option. If no > new lifetime is received, it MUST behave as if no value was ever > provided. > >In line with that SHOULD, there's no good reason to have multiple >lifetimes. > >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 Tue Aug 3 14:32:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00023; Tue, 3 Aug 2004 14:32:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3pA-0002p9-Hm; Tue, 03 Aug 2004 14:15:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3bK-0007sJ-9q for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 14:01:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27434 for ; Tue, 3 Aug 2004 14:01:25 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3eQ-0006OL-9O for dhcwg@ietf.org; Tue, 03 Aug 2004 14:04:40 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i73I1MnE025323 for ; Tue, 3 Aug 2004 19:01:22 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA11209 for ; Tue, 3 Aug 2004 19:01:21 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i73I1LO22383 for dhcwg@ietf.org; Tue, 3 Aug 2004 19:01:21 +0100 Date: Tue, 3 Aug 2004 19:01:21 +0100 From: Tim Chown To: dhcwg@ietf.org Message-ID: <20040803180121.GC21469@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [dhcwg] My slides for dhc session, 3rd Aug 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, My slides are available temporarily online: Draft: http://www.ietf.org/internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt Slides: http://www.ecs.soton.ac.uk/~tjc/ietf/stateless-renumbering-01.pdf http://www.ecs.soton.ac.uk/~tjc/ietf/stateless-renumbering-01.ppt Draft: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dual-stack-01.txt Slides: http://www.ecs.soton.ac.uk/~tjc/ietf/dhcp-dual-stack-01.pdf http://www.ecs.soton.ac.uk/~tjc/ietf/dhcp-dual-stack-01.ppt Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 14:33:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00270; Tue, 3 Aug 2004 14:33:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3pO-0002tR-T8; Tue, 03 Aug 2004 14:15:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3dR-00086D-2e for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 14:03:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27594 for ; Tue, 3 Aug 2004 14:03:35 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3gX-0006Qg-5n for dhcwg@ietf.org; Tue, 03 Aug 2004 14:06:50 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73I32e25363 for ; Tue, 3 Aug 2004 21:03:02 +0300 Date: Tue, 3 Aug 2004 21:03:02 +0300 (EEST) From: Pekka Savola To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [dhcwg] Trust model of Client FQDN option 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, (not subscribed..) I'm not sure the v4 or v6 DHC FQDN client options address the problem of the trust model for the update content sufficiently well. I'd even go as far to say that it might create a false sense of security. The issue is that as the DNS server will be configured to trust the DHCP server for these updates, how could the DHCP server ensure that the Client is authorized to insert that FQDN -> IP mapping. This is basically deemed outside of the scope of the spec, without providing the means in the spec to do that properly. A suggestion is that the DHCP server includes policy information which updates would be acceptable. I do not think this addresses the real problem: if such policy is available, why does the client need to send the FQDN in the first place -- the DHCP server should just be configured to update the FQDN corresponding to a particular client to map to the IP address of that client; the client doesn't need to specify it if this will need to be included in the policy configuration in any case. So, in this kind of scenario, you shouldn't actually need the Client FQDN option here, just the magic in the DHCP server to update the IP address of a particular client automatically. Therefore, the client should probably be able to insert a TSIG or some other signature which the DHCP server could use for updating; this would authorize the update (in case TSIG validation succeeds) or not without manually configured policy lists. (A reason why DHCP server could update the FQDN to the DNS server might be that the ISP wants to restrict access to the DNS updates to a smaller number of hosts.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 15:04:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03134; Tue, 3 Aug 2004 15:04:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs4SC-00011a-6E; Tue, 03 Aug 2004 14:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs4Md-0008Fw-Q5 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 14:50:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01997 for ; Tue, 3 Aug 2004 14:50:18 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs4Pk-0007Xh-SL for dhcwg@ietf.org; Tue, 03 Aug 2004 14:53:34 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2004 14:49:48 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i73InjRW007134; Tue, 3 Aug 2004 14:49:45 -0400 (EDT) Received: from volzw2k (tky-vpn-client-231-28.cisco.com [10.70.231.28]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO73605; Tue, 3 Aug 2004 14:49:37 -0400 (EDT) From: "Bernie Volz" To: , , Subject: RE: [dhcwg] RE: draft-chowdhury-dhc-bcmcv4-option-00.txt Date: Tue, 3 Aug 2004 14:50:26 -0400 Organization: Cisco Message-ID: <000001c4798a$c24c13f0$46828182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal In-Reply-To: <000301c4791b$76cf1fe0$3e858182@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "'DHC WG \(E-mail\)'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Ignore the broadcast comment ... - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Bernie Volz > Sent: Tuesday, August 03, 2004 1:34 AM > To: chowdury@nortelnetworks.com; pyegani@cisco.com; > Lila.Madour@ericsson.com > Cc: 'DHC WG (E-mail)' > Subject: [dhcwg] RE: draft-chowdhury-dhc-bcmcv4-option-00.txt > > > While preparing for the DHC WG meeting, I found these issues with > draft-chowdhury-dhc-bcmcv6-option-00.txt: > > As DHCPv6 doesn't support broadcasting, you're really only > able to support multicasting. Not sure if this should be > pointed out early in the draft? And, perhaps the option (in > the DHCPv6 case) should not use "broadcast" in its name? > > RFC 3315, section 8, specifically prohibits compression. You > should follow that rule. > > Informative is misspelling in this document as well (inforamtive). > > - Bernie > > > _______________________________________________ > 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 Tue Aug 3 16:30:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09415; Tue, 3 Aug 2004 16:30:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5nx-0005x1-L1; Tue, 03 Aug 2004 16:22:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5jZ-0005Px-An for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:18:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08690 for ; Tue, 3 Aug 2004 16:18:03 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs5mh-0000bp-1P for dhcwg@ietf.org; Tue, 03 Aug 2004 16:21:20 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1W00K040D7IC@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:17:31 +0900 (KST) Received: from ep_ms3_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1W001QS0D7S1@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:17:31 +0900 (KST) Received: from ep_spt01 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1W003M30D71R@ms3.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:17:31 +0900 (KST) Content-return: prohibited Date: Tue, 03 Aug 2004 20:17:38 +0000 (GMT) From: PARK SOO HONG Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: Ted Lemon Message-id: <0I1W003M40D71R@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20040803201723656@soohong.park X-MTR: 20040803201723656@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Score: 1.7 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "dhcwg@ietf.org " X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331195655==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0331195655== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

>However, I would like to point out one problem with this, and request 
>that the authors of these drafts (I'm thinking specifically of the 
>haopt and tep drafts) add some text to talk about what the client 
>should send in the parameter request list.

So I simply wrote some text in my draft.

 

The DHCP client will use this option to create a tunnel end-point address

for configuring IPv6-over-IPv4 tunnel. The client may receive tunnel services

in this option that it does not support or has not been configured to access.

Likewise, a client may receive an option that tunnel services for which no

corresponding DHCP option was supplied. Clients will interpret this option

in a system-specific manner whose specification is outside the scope of

this document.

 

 

Isn't it enough to satisfy your concern ?

This text is our implementation-basis

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


--===============0331195655== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0331195655==-- From dhcwg-bounces@ietf.org Tue Aug 3 16:49:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10833; Tue, 3 Aug 2004 16:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs68a-00005W-Bp; Tue, 03 Aug 2004 16:43:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs63T-0007bx-8F for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:38:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10185 for ; Tue, 3 Aug 2004 16:38:37 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs66a-0000yf-Tr for dhcwg@ietf.org; Tue, 03 Aug 2004 16:41:54 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1W00L011BHGY@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:38:05 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1W00BDA1BG0W@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:38:05 +0900 (KST) Received: from Alperyegin ([105.253.155.49]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I1W00KCP1BC90@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:38:04 +0900 (KST) Date: Tue, 03 Aug 2004 13:38:00 -0700 From: Alper Yegin In-reply-to: <000101c4791b$739a81c0$3e858182@amer.cisco.com> To: "'Bernie Volz'" , heejin.jang@samsung.com, athene@sait.samsung.co.kr Message-id: <000001c47999$c6900160$be818182@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7BIT Cc: "'DHC WG \(E-mail\)'" Subject: [dhcwg] RE: draft-jang-dhc-haopt-00.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Bernie, Thank you for the review and feedback. > In DHCPv6 we use 16-bit option (and suboption) codes and lengths. It would > be best if this draft switched to using 16-bit fields for the sub-option > and > length fields. Please see RFC 3315 and section 22.17. Note also that for > some forms of identification/authentication (opaque type), it is > conceivable > that it might exceed a length of 255 bytes! We will fix that. > Also, with a 16-bit option number space, we've got plenty of option number > space and it might be best to drop the Home Agent Discovery Option and > simply make the two sub-options regular options? Or, is there a reason > you'd > prefer having sub-options? Nothing other than clumping the related information together. We can split the options if this is the preferred way. > For the Home Network Information Sub-option, I assume that if multiple > addresses (or prefixes) are specified, the A, reserved, prefix-length and > address/prefix fields are all repeated (18 bytes/address). It might be > good > to specify this? Yes, that's the intent. We'll add more text to clarify this. Thanks again. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 17:07:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12041; Tue, 3 Aug 2004 17:07:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6Rf-0002oG-LS; Tue, 03 Aug 2004 17:03:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6KQ-0001yF-VM for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11305 for ; Tue, 3 Aug 2004 16:56:08 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6NY-0001GR-Qb for dhcwg@ietf.org; Tue, 03 Aug 2004 16:59:26 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1W00E0124PJZ@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:55:37 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1W005LD24OKF@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:55:37 +0900 (KST) Received: from Alperyegin ([105.253.155.49]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I1W00KT224L90@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:55:36 +0900 (KST) Date: Tue, 03 Aug 2004 13:55:32 -0700 From: Alper Yegin Subject: RE: [dhcwg] How does DHCP client know when it's at home? In-reply-to: <20040803175702.GA28332@sverresborg.uninett.no> To: "'Stig Venaas'" , dhcwg@ietf.org Message-id: <000001c4799c$39a8a830$be818182@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Stig, > Regarding the MIPv6 HA option, it was suggested that client would use > this when at home, and ignore the option if it gets something when not > at home. Unfortunately that is not accurate. I should have corrected that at the meeting. The current I-D has the provision to deliver home agent info that pertains to the currently visited network, or a remote network. The MNId is used to convey the domain the information should pertain to. My MN should be able to say "get me a home agent from the access network I'm visiting", or "give me a home agent from anotherdomain.com". > I don't understand how a client can know when it's at home, are there > any mechanisms for that? > > If it is, it might be more useful to also have DHCP options for things > like POP/IMAP servers etc where you want to learn the addresses when > at home, and keep using the same when away. > > Stig Alper > > _______________________________________________ > 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 Tue Aug 3 18:19:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17665; Tue, 3 Aug 2004 18:19:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7aV-0001jN-E5; Tue, 03 Aug 2004 18:16:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7R7-0005kW-3I for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 18:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16302 for ; Tue, 3 Aug 2004 18:07:06 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7UF-0002Qt-Pl for dhcwg@ietf.org; Tue, 03 Aug 2004 18:10:25 -0400 Received: from [66.93.162.248] (0127bhost250.starwoodbroadband.com [12.105.247.250]) by toccata.fugue.com (Postfix) with ESMTP id 08D961B24B0; Tue, 3 Aug 2004 17:06:18 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <72FA02EA-E599-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] one more comment about the lifetime option Date: Tue, 3 Aug 2004 15:07:02 -0700 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 10:03 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > Is it possible to specify different lifetimes for different instances > of stateless information? For example, people may want to specify > different lifetimes for recursive DNS server addresses and for SIP > server addresses. I think the amount of work the server has to do to make this happen is more than the amount of work that is saved. That is, you're going to have to process an Information Request packet every time anything on the client expires. And figuring out that you only need to send certain options, and not certain others, is more work than just sending what you have. So I think that not only is it not necessary to have different lifetimes for different options, it's actually harmful to have them. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 18:30:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18254; Tue, 3 Aug 2004 18:30:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7ie-0003RI-LF; Tue, 03 Aug 2004 18:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7cn-0002n7-Jd for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 18:19:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17700 for ; Tue, 3 Aug 2004 18:19:10 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7ft-0002bv-WB for dhcwg@ietf.org; Tue, 03 Aug 2004 18:22:29 -0400 Received: from [66.93.162.248] (0127bhost250.starwoodbroadband.com [12.105.247.250]) by toccata.fugue.com (Postfix) with ESMTP id ACA0B1B29EB; Tue, 3 Aug 2004 17:18:20 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option Date: Tue, 3 Aug 2004 15:19:05 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > I'm not sure the v4 or v6 DHC FQDN client options address the problem > of the trust model for the update content sufficiently well. I'd even > go as far to say that it might create a false sense of security. Pekka, in the meeting this morning, you said you hadn't read the drafts having to do with DNS updates on DHCPv4. Have you now read them? The reason I ask is that for the entire duration of the time I've been coming to IETF, people have occasionally raised the very same issue you are now raising. The solution we have adopted, which is widely deployed, allows two answers to your question. The first is a more paranoid solution that requires widespread distribution of individual DNS update keys. The second is a more laissez-faire solution that does not require the distribution of individual DNS update keys. This second solution is no more or less secure than the first, but its behavior is different. Names added by the DHCP server are marked as such, and if a name is present and was not added by the DHCP server, that name can't be replaced at the request of the DHCP client. When a client's lease expires, another client can acquire the previous client's name, so there's no protection for client names. You get to pick which solution to deploy, based on your willingness to distribute keys and based on whether or not you care whether a DHCP client can count on retaining its name, once its name is registered. So this is a well-understood problem, with well-understood and widely deployed solutions. You can see an example implementation in the ISC DHCP client and server if you're curious, and as far as I know every commercial DHCP server also implements this, and I know of quite a few sites that use it in practice. Indeed, it's been deployed at IETF meetings in the past (not sure if it's running this time). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 18:37:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18680; Tue, 3 Aug 2004 18:37:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7rs-0004GU-Fq; Tue, 03 Aug 2004 18:34:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7jR-0003YA-Fw for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 18:26:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18101 for ; Tue, 3 Aug 2004 18:26:03 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7ma-0002j2-DA for dhcwg@ietf.org; Tue, 03 Aug 2004 18:29:21 -0400 Received: from [66.93.162.248] (0127bhost250.starwoodbroadband.com [12.105.247.250]) by toccata.fugue.com (Postfix) with ESMTP id 44AC11B2A2E; Tue, 3 Aug 2004 17:25:15 -0500 (CDT) In-Reply-To: <0I1W003M40D71R@ms3.samsung.com> References: <0I1W003M40D71R@ms3.samsung.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <18347D18-E59C-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 15:25:59 -0700 To: soohong.park@samsung.com X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 1:17 PM, PARK SOO HONG wrote: > Isn't it enough to satisfy your concern ? No, my concern is not related to what you're talking about. My concern is actually unrelated to the work you are doing - I'm just asking you to add some text to try to get client implements to be consistent in what they do with the parameter request list. It's not your fault that this is (IMHO) necessary - the problem is that the parameter request list option is poorly specified, and I'd like implementors of this option to implement to the more stringent interpretation of the specification, rather than the more lax implementation. In order to get client implementors to do this, I am asking you to add some text which will (I hope) cause client implementors to assume that the DHCP server will behave in a certain way. If they believe that a DHCP server will very likely not send a tep option if the client doesn't request it in the parameter request list, then they will request it in the parameter request list. If they do not believe this, then they may send a parameter request list but omit the tep option code from the list, thinking it is not necessary to include it. I don't actually care if server implementors follow the requirements I'm asking you to add - I just care that client implementors have reason to think that servers might follow these requirements. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 19:16:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20681; Tue, 3 Aug 2004 19:16:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8SV-00081k-Qo; Tue, 03 Aug 2004 19:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8Ma-0007ST-W8 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 19:06:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20244 for ; Tue, 3 Aug 2004 19:06:30 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs8Pj-0003HZ-Pe for dhcwg@ietf.org; Tue, 03 Aug 2004 19:09:49 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73N5ua31874; Wed, 4 Aug 2004 02:05:56 +0300 Date: Wed, 4 Aug 2004 02:05:56 +0300 (EEST) From: Pekka Savola To: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option In-Reply-To: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, 3 Aug 2004, Ted Lemon wrote: > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > > I'm not sure the v4 or v6 DHC FQDN client options address the problem > > of the trust model for the update content sufficiently well. I'd even > > go as far to say that it might create a false sense of security. > > Pekka, in the meeting this morning, you said you hadn't read the drafts > having to do with DNS updates on DHCPv4. Have you now read them? Yes; I scanned through draft-ietf-dhc-fqdn-option and the dnxext dhcrr document. > The reason I ask is that for the entire duration of the time I've been > coming to IETF, people have occasionally raised the very same issue you > are now raising. Maybe this would stop if these issues would actually be adequately addressed? I promise to bring this up again at the last minute if not. What you describe below is very well, and probably addresses most of the issues (to a certain degree, which should be spelled out), but none of this seems to exist written in the clear in draft-ietf-dhc-fqdn-option. Let's look at its Security Considerations section (the others don't include anything relevant to this, AFAICS): 1st paragraph: generic text about DNS update authentication requirements 2nd: notes the two approaches (client vs dhcp updated), and that they depend e.g., on security model (without going into details) 3rd: generic text wrt. whether DHCP server would always do the updates or not 4th: notes the lack of authentication of the user, given that DHCP authentication is not there or is not deployed. Ascertaining the identty of the client is difficult. [note: DHCP authentication has very little to do with the authorization of the client to update a specific name] 5th: describes scenarios where you might not be able to spoof DHCP packets, and a little text about being able to trust (in some cases) the dhc client id. [note: spoofing or not spoofing DHCP packets, and DHC client id do not yet provide any authorization to update a DNS name] I also note that the draft doesn't even mention draft-ietf-dnsext-dhcid-rr-08.txt. The actual meat is missing, and does not address *DNS name* authorization at all, just talks quite a bit about DHCP authentication and different ways to eliminate DHCP spoofing. > The solution we have adopted, which is widely deployed, allows two > answers to your question. The first is a more paranoid solution that > requires widespread distribution of individual DNS update keys. The > second is a more laissez-faire solution that does not require the > distribution of individual DNS update keys. This second solution is > no more or less secure than the first, but its behavior is different. > Names added by the DHCP server are marked as such, and if a name is > present and was not added by the DHCP server, that name can't be > replaced at the request of the DHCP client. When a client's lease > expires, another client can acquire the previous client's name, so > there's no protection for client names. You get to pick which > solution to deploy, based on your willingness to distribute keys and > based on whether or not you care whether a DHCP client can count on > retaining its name, once its name is registered. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 19:50:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22782; Tue, 3 Aug 2004 19:50:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8sq-000298-6R; Tue, 03 Aug 2004 19:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8nd-0001Mv-Ri for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 19:34:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21796 for ; Tue, 3 Aug 2004 19:34:28 -0400 (EDT) Received: from web90006.mail.scd.yahoo.com ([66.218.94.64]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bs8qn-0003iV-Am for dhcwg@ietf.org; Tue, 03 Aug 2004 19:37:46 -0400 Message-ID: <20040803233353.81715.qmail@web90006.mail.scd.yahoo.com> Received: from [130.129.64.82] by web90006.mail.scd.yahoo.com via HTTP; Tue, 03 Aug 2004 16:33:53 PDT Date: Tue, 3 Aug 2004 16:33:53 -0700 (PDT) From: Syam Madanapalli Subject: Re:[dhcwg] comments on draft-daniel-dhc-dhcpv4-tep-conf To: Ted.Lemon@nominum.com, dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.5 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello Ted Lemon , This draft breaks a couple of existing assumptions about DHCP. First, it requires that the option be send only in a DHCPACK message in response to a DHCPREQUEST message. Normally the DHCPOFFER message contains the same options as the DHCPACK message. So I would strongly suggest that this restriction be relaxed to allow the DHCPOFFER to contain this option. ---> Initially we have taken this approach, so that we could establish the bidirectional tunnel simultaneously at both the places. With your proposal now we can create the tunnel only one side, the other side need to repeat this procedure to create the other end of the tunnel. To overcome this we have new proposal where DHCP Inform is used to to create the tunnel. Following link has the PPT http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt Secondly, the draft allows multiple copies to appear. This contradicts the Encoding Long Options RFC (sorry, can't remember the number off the top of my head), which would create a huge headache for DHCP server and client implementations. So please change the option so that there can be only one of them, and that if multiple values need to be sent, that is encoded within the option. ---> Yep, we will make this change. Also, there is quite a bit of information in this document that goes beyond describing the format of the option. It looks like you're defining a new protocol. If you are not defining a new protocol, it would be better to refer to the document that defines the protocol, and remove the words from this document that describe that protocol in detail. If you are defining a new protocol here, this draft probably needs to be reviewed by the working group responsible for that area as well as by the DHC working group. (sorry if this has already been said) ---> The intention of the draft is to propose an Option as well as a protocol (may be a procedure) to automate the tunnel configuration acroos IPv6 Clouds seperated by v4 network. And this draft recommends running a DHCP Client on a border dual Stack router, I am not sure if this is okay. Otherwise you need another protocol between DHCP Client and router to configure Tunnel end points automatically. I've enclosed a couple of diffs for some minor editorial suggestions. Attachment: draft-daniel-dhc-dhcpv4-tep-conf-comments ---> We will take these suggestions. Thank you, Syam __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 20:08:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24232; Tue, 3 Aug 2004 20:08:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9JK-0006qa-2I; Tue, 03 Aug 2004 20:07:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs97b-0004nt-LL for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 19:55:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23203 for ; Tue, 3 Aug 2004 19:55:06 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9Al-00047t-9X for dhcwg@ietf.org; Tue, 03 Aug 2004 19:58:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2004 16:56:09 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i73NsVJI017108; Tue, 3 Aug 2004 16:54:31 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com (rtp-vpn1-257.cisco.com [10.82.225.1]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO95097; Tue, 3 Aug 2004 19:54:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20040803194603.026f35b0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 19:55:52 -0400 To: Ted Lemon , soohong.park@samsung.com From: Kim Kinnear Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... In-Reply-To: <18347D18-E59C-11D8-8860-000A95D9C74C@nominum.com> References: <0I1W003M40D71R@ms3.samsung.com> <0I1W003M40D71R@ms3.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "dhcwg@ietf.org " , 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At 06:25 PM 8/3/2004, Ted Lemon wrote: >On Aug 3, 2004, at 1:17 PM, PARK SOO HONG wrote: >>Isn't it enough to satisfy your concern ? > >No, my concern is not related to what you're talking about. My concern is actually unrelated to the work you are doing - I'm just asking you to add some text to try to get client implements to be consistent in what they do with the parameter request list. It's not your fault that this is (IMHO) necessary - the problem is that the parameter request list option is poorly specified, and I'd like implementors of this option to implement to the more stringent interpretation of the specification, rather than the more lax implementation. > >In order to get client implementors to do this, I am asking you to add some text which will (I hope) cause client implementors to assume that the DHCP server will behave in a certain way. If they believe that a DHCP server will very likely not send a tep option if the client doesn't request it in the parameter request list, then they will request it in the parameter request list. If they do not believe this, then they may send a parameter request list but omit the tep option code from the list, thinking it is not necessary to include it. > >I don't actually care if server implementors follow the requirements I'm asking you to add - I just care that client implementors have reason to think that servers might follow these requirements. Ted, Thank you for such a clear statement of this issue. I agree that the parameter request option is poorly specified, and I remember my astonishment the first time I heard the interpretation that a DHCP server should send *every* option with which it is configured (and not just the options that were requested in the parameter request list). That wasn't my interpretation of the DHCP draft/RFC and it seems it wasn't yours either. I also agree with your goal -- that client implementors *must* ask (via the paramter request list) for options that they need, and not assume that the DHCP server will just send send them by magic. I believe that the way to achieve that goal is to simply put that in the RFC -- that a client that needs this option MUST request it via the parameter request list. I strongly believe that saying that a DHCP server MUST NOT send this option unless a client requests it is very much not the way to achieve this end. This will require special case code in every DHCP server which wants to be compliant with this draft (and future RFC). I see this as a "cure worse than the disease". Let us just say what we mean -- a client that wants this option MUST request it by using the parameter request list. Period. Cheers -- Kim >_______________________________________________ >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 GREZUMU@yahoo.com Tue Aug 3 20:30:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25566; Tue, 3 Aug 2004 20:30:18 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9iq-0004r7-HP; Tue, 03 Aug 2004 20:33:36 -0400 Received: from [200.92.211.165] (helo=customer-PUE-211-165.megared.net.mx) by mx2.foretec.com with smtp (Exim 4.24) id 1Bs9fc-0002jq-O8; Tue, 03 Aug 2004 20:30:17 -0400 Received: from 136.230.52.48 by web404.mail.yahoo.com; Tue, 03 Aug 2004 18:30:03 -0700 Message-ID: From: "Arline Farley" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Best software prices. Date: Tue, 03 Aug 2004 22:23:03 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2228001684752613727" X-CS-IP: 128.99.101.235 X-Spam-Score: 5.1 (+++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----2228001684752613727 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable TOP quality software:

Special Offer #1:
Windows XP P= rofessional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe - P= hotoshop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macrom= edia Dreamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter H= ere











?HqdMdYb2YfOAZHHchinook|= dhcipv6-archive@ietf.org">or un*su*bs*cr*ibe =20 ----2228001684752613727-- From dhcwg-bounces@ietf.org Tue Aug 3 20:53:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27383; Tue, 3 Aug 2004 20:53:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9wV-0005uv-WF; Tue, 03 Aug 2004 20:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9tn-0004mY-DS for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 20:44:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26625 for ; Tue, 3 Aug 2004 20:44:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9wv-00058D-IX for dhcwg@ietf.org; Tue, 03 Aug 2004 20:48:12 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2004 20:44:21 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i740iDxF001583; Tue, 3 Aug 2004 20:44:16 -0400 (EDT) Received: from volzw2k (sjc-vpn3-608.cisco.com [10.21.66.96]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO96850; Tue, 3 Aug 2004 20:40:58 -0400 (EDT) From: "Bernie Volz" To: "'Pekka Savola'" , "'Ted Lemon'" Subject: RE: [dhcwg] Trust model of Client FQDN option Date: Tue, 3 Aug 2004 20:42:26 -0400 Organization: Cisco Message-ID: <000c01c479bb$eba91af0$c3838182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Correct, this appears in draft-ietf-dhc-ddns-resolution-07.txt. This draft is referenced in the "7. DNS Update Conflicts" section of the FQDN draft. The resolution draft still needs additional work for DHCPv6 - it currently only applies to IPv4. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Pekka Savola > Sent: Tuesday, August 03, 2004 7:06 PM > To: Ted Lemon > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Trust model of Client FQDN option > > > On Tue, 3 Aug 2004, Ted Lemon wrote: > > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > > > I'm not sure the v4 or v6 DHC FQDN client options address the > > > problem of the trust model for the update content > sufficiently well. > > > I'd even go as far to say that it might create a false sense of > > > security. > > > > Pekka, in the meeting this morning, you said you hadn't > read the drafts > > having to do with DNS updates on DHCPv4. Have you now > read them? > > Yes; I scanned through draft-ietf-dhc-fqdn-option and the > dnxext dhcrr > document. > > > The reason I ask is that for the entire duration of the > time I've been > > coming to IETF, people have occasionally raised the very > same issue you > > are now raising. > > Maybe this would stop if these issues would actually be > adequately addressed? I promise to bring this up again at > the last minute if > not. > > What you describe below is very well, and probably addresses > most of the issues (to a certain degree, which should be > spelled out), but none of this seems to exist written in the > clear in draft-ietf-dhc-fqdn-option. > > Let's look at its Security Considerations section (the others don't > include anything relevant to this, AFAICS): > > 1st paragraph: generic text about DNS update authentication > requirements > > 2nd: notes the two approaches (client vs dhcp updated), and that they > depend e.g., on security model (without going into details) > > 3rd: generic text wrt. whether DHCP server would always do > the updates > or not > > 4th: notes the lack of authentication of the user, given that DHCP > authentication is not there or is not deployed. Ascertaining the > identty of the client is difficult. [note: DHCP authentication has > very little to do with the authorization of the client to update a > specific name] > > 5th: describes scenarios where you might not be able to spoof DHCP > packets, and a little text about being able to trust (in some cases) > the dhc client id. [note: spoofing or not spoofing DHCP packets, and > DHC client id do not yet provide any authorization to update a DNS > name] > > I also note that the draft doesn't even mention > draft-ietf-dnsext-dhcid-rr-08.txt. > > The actual meat is missing, and does not address *DNS name* > authorization at all, just talks quite a bit about DHCP > authentication and different ways to eliminate DHCP spoofing. > > > The solution we have adopted, which is widely deployed, allows two > > answers to your question. The first is a more paranoid > solution that > > requires widespread distribution of individual DNS update > keys. The > > second is a more laissez-faire solution that does not require the > > distribution of individual DNS update keys. This second > solution is > > no more or less secure than the first, but its behavior is > different. > > Names added by the DHCP server are marked as such, and if a name is > > present and was not added by the DHCP server, that name can't be > > replaced at the request of the DHCP client. When a client's lease > > expires, another client can acquire the previous client's name, so > > there's no protection for client names. You get to pick which > > solution to deploy, based on your willingness to distribute > keys and > > based on whether or not you care whether a DHCP client can count on > > retaining its name, once its name is registered. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > 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 Tue Aug 3 20:55:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27533; Tue, 3 Aug 2004 20:55:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9wX-0005vg-JJ; Tue, 03 Aug 2004 20:47:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9uS-0004xK-Tw for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 20:45:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26679 for ; Tue, 3 Aug 2004 20:45:35 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9xb-000592-4W for dhcwg@ietf.org; Tue, 03 Aug 2004 20:48:54 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2004 17:46:38 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i740iubA021493; Tue, 3 Aug 2004 17:45:00 -0700 (PDT) Received: from volzw2k (sjc-vpn3-608.cisco.com [10.21.66.96]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO96757; Tue, 3 Aug 2004 20:37:58 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" , "'Pekka Savola'" Subject: RE: [dhcwg] Trust model of Client FQDN option Date: Tue, 3 Aug 2004 20:39:25 -0400 Organization: Cisco Message-ID: <000b01c479bb$81780bf0$c3838182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Also, it is generally viewed as a bad idea to mix both static and dynamic DNS resource records in a zone. So, if you want to completely avoid the problem, keep the zones which contain the administrative DNS information (www., ftp., pop3., ...) separate from the (dynamic) client information. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Ted Lemon > Sent: Tuesday, August 03, 2004 6:19 PM > To: Pekka Savola > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Trust model of Client FQDN option > > > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > > I'm not sure the v4 or v6 DHC FQDN client options address > the problem > > of the trust model for the update content sufficiently > well. I'd even > > go as far to say that it might create a false sense of security. > > Pekka, in the meeting this morning, you said you hadn't read > the drafts > having to do with DNS updates on DHCPv4. Have you now read them? > The reason I ask is that for the entire duration of the time > I've been > coming to IETF, people have occasionally raised the very same > issue you > are now raising. > > The solution we have adopted, which is widely deployed, allows two > answers to your question. The first is a more paranoid > solution that > requires widespread distribution of individual DNS update keys. The > second is a more laissez-faire solution that does not require the > distribution of individual DNS update keys. This second solution is > no more or less secure than the first, but its behavior is > different. > Names added by the DHCP server are marked as such, and if a name is > present and was not added by the DHCP server, that name can't be > replaced at the request of the DHCP client. When a client's lease > expires, another client can acquire the previous client's name, so > there's no protection for client names. You get to pick which > solution to deploy, based on your willingness to distribute keys and > based on whether or not you care whether a DHCP client can count on > retaining its name, once its name is registered. > > So this is a well-understood problem, with well-understood and widely > deployed solutions. You can see an example implementation > in the ISC > DHCP client and server if you're curious, and as far as I know every > commercial DHCP server also implements this, and I know of > quite a few > sites that use it in practice. Indeed, it's been deployed at IETF > meetings in the past (not sure if it's running this time). > > > _______________________________________________ > 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 Tue Aug 3 21:13:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28576; Tue, 3 Aug 2004 21:13:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAFE-0000MP-UA; Tue, 03 Aug 2004 21:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsADd-00005E-Bx for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 21:05:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28063 for ; Tue, 3 Aug 2004 21:05:23 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsAGn-0005Uy-Qy for dhcwg@ietf.org; Tue, 03 Aug 2004 21:08:43 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2004 21:09:39 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7412CRW010506; Tue, 3 Aug 2004 21:02:12 -0400 (EDT) Received: from volzw2k (sjc-vpn3-608.cisco.com [10.21.66.96]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO97662; Tue, 3 Aug 2004 21:02:11 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" , Subject: RE: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 21:03:39 -0400 Organization: Cisco Message-ID: <001401c479be$e1045080$c3838182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <7C7FE7F6-E565-11D8-982E-000A95D9C74C@nominum.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted: I can add this to the FQDN drafts (PRL for DHCPv4 and ORO for DHCPv6), = but it seems odd to do this for options that are designed to be = bi-directional. Yet, as Kim did request that I make it clear that a server can send the option to a client even if the client doesn't supply it, it seems = reasonable that a client could request it in the PRL or ORO (without sending it). = And, if we allow that, including it in the PRL or ORO even if the option is included by the client is OK. I haven't checked and don't recall, but do you know whether existing = clients generally include it in the PRL today? - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Tuesday, August 03, 2004 11:55 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Comment on a couple of option drafts that=20 > have gone by... >=20 >=20 > I've noticed that a couple of drafts have gone by that require the=20 > client to send an option to the server so that the server will know=20 > what to send back to the client. In each of these cases, this seems=20 > like a reasonable way to solve the problem. >=20 > However, I would like to point out one problem with this, and request=20 > that the authors of these drafts (I'm thinking specifically of the=20 > haopt and tep drafts) add some text to talk about what the client=20 > should send in the parameter request list. >=20 > Currently the FQDN option protocol specification requires the=20 > server to=20 > send back an FQDN option even if the client sends a parameter request=20 > list and doesn't include the FQDN option code in that list. Please=20 > specify in your drafts that the DHCP server must not send the reply=20 > option unless either no parameter request list is sent, or unless the=20 > option code for the option appears in the parameter request list. =20 > Suggested text: >=20 > The DHCP server MUST NOT send the Foo option if the client sends a=20 > Parameter Request List option and the code for the Foo option=20 > does not=20 > appear in the parameter request list, EVEN IF the Foo-request option=20 > appears in the client's list of options. >=20 > The reason for making this request is that we have to have=20 > special case=20 > code in the DHCP server to make sure the FQDN option gets=20 > sent even if=20 > not requested, and this adds needless complexity. If you add text=20 > like what I've suggested above, you are not placing this=20 > requirement on=20 > the server - the server can just process the option normally when=20 > constructing the reply. >=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 From dhcwg-bounces@ietf.org Tue Aug 3 21:15:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28742; Tue, 3 Aug 2004 21:15:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAM2-0001Uu-Qz; Tue, 03 Aug 2004 21:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAG3-0000Xo-RA for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 21:07:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28224 for ; Tue, 3 Aug 2004 21:07:54 -0400 (EDT) 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.33) id 1BsAJD-0005YA-32 for dhcwg@ietf.org; Tue, 03 Aug 2004 21:11:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2004 18:08:12 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7417KIt005825; Tue, 3 Aug 2004 18:07:21 -0700 (PDT) Received: from mjs-xp.cisco.com (sjc-vpn2-504.cisco.com [10.21.113.248]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO97910; Tue, 3 Aug 2004 21:07:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20040803172917.01d61710@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 18:06:18 -0700 To: Pekka Savola From: Mark Stapp Subject: Re: [dhcwg] Trust model of Client FQDN option In-Reply-To: References: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: dhcwg@ietf.org, Ted Lemon 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org how an administrator controls dns updates is not _really_ a dhcp protocol issue. there is no standardized way to express dns update policy, and, as a policy issue, it's not really an ietf issue at all, in my opinion. I can think of several possible ways that a dns administrator might configure his or her dns servers: 1. use a zone-wide TSIG key and allow any update to any name, trusting any updater who presents a valid TSIG key 2. provision a different key for each name; only allow an updater to update a name if it presents the 'right' key for that name 3. use zone-wide TSIG keys, but prohibit dns updates to some names, period now (1) is a bit weak, though it is used, and (2) presents a significant key-distribution hurdle. (3) is frequently done in the field, and we have years of field experience with it in v4. having a dhcp option that carries an fqdn does not give any client license to use the server as a dns update proxy. it also does not relieve dns administrators of the responsibility to establish some policy about updates. there are sites that don't allow _any_ updates from anyone - that's a valid policy too. for many other sites, however, having a dhcp server and then a dns server each have an opportunity to apply some policy about the names that can be updated is efficient and effective. perhaps you'd like it if some drafts' security considerations sections said: "watch out, because some dhcp client might present 'www' in its FQDN option, and you might not want to let that update happen." that'd be fine, but that's about as far as it can go, because there is a wide range of update policies in place in the field. -- Mark At 02:05 AM 8/4/2004 +0300, Pekka Savola wrote: >On Tue, 3 Aug 2004, Ted Lemon wrote: > > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > > > I'm not sure the v4 or v6 DHC FQDN client options address the problem > > > of the trust model for the update content sufficiently well. I'd even > > > go as far to say that it might create a false sense of security. > > > > Pekka, in the meeting this morning, you said you hadn't read the drafts > > having to do with DNS updates on DHCPv4. Have you now read them? > >Yes; I scanned through draft-ietf-dhc-fqdn-option and the dnxext dhcrr >document. > > > The reason I ask is that for the entire duration of the time I've been > > coming to IETF, people have occasionally raised the very same issue you > > are now raising. > >Maybe this would stop if these issues would actually be adequately >addressed? I promise to bring this up again at the last minute if >not. > >What you describe below is very well, and probably addresses most of >the issues (to a certain degree, which should be spelled out), but >none of this seems to exist written in the clear in >draft-ietf-dhc-fqdn-option. > >Let's look at its Security Considerations section (the others don't >include anything relevant to this, AFAICS): > >1st paragraph: generic text about DNS update authentication >requirements > >2nd: notes the two approaches (client vs dhcp updated), and that they >depend e.g., on security model (without going into details) > >3rd: generic text wrt. whether DHCP server would always do the updates >or not > >4th: notes the lack of authentication of the user, given that DHCP >authentication is not there or is not deployed. Ascertaining the >identty of the client is difficult. [note: DHCP authentication has >very little to do with the authorization of the client to update a >specific name] > >5th: describes scenarios where you might not be able to spoof DHCP >packets, and a little text about being able to trust (in some cases) >the dhc client id. [note: spoofing or not spoofing DHCP packets, and >DHC client id do not yet provide any authorization to update a DNS >name] > >I also note that the draft doesn't even mention >draft-ietf-dnsext-dhcid-rr-08.txt. > >The actual meat is missing, and does not address *DNS name* >authorization at all, just talks quite a bit about DHCP authentication >and different ways to eliminate DHCP spoofing. > > > The solution we have adopted, which is widely deployed, allows two > > answers to your question. The first is a more paranoid solution that > > requires widespread distribution of individual DNS update keys. The > > second is a more laissez-faire solution that does not require the > > distribution of individual DNS update keys. This second solution is > > no more or less secure than the first, but its behavior is different. > > Names added by the DHCP server are marked as such, and if a name is > > present and was not added by the DHCP server, that name can't be > > replaced at the request of the DHCP client. When a client's lease > > expires, another client can acquire the previous client's name, so > > there's no protection for client names. You get to pick which > > solution to deploy, based on your willingness to distribute keys and > > based on whether or not you care whether a DHCP client can count on > > retaining its name, once its name is registered. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >_______________________________________________ >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 Tue Aug 3 23:09:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06268; Tue, 3 Aug 2004 23:09:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsC1F-00078e-8Y; Tue, 03 Aug 2004 23:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsByO-0006ov-FM for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 22:57:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05019 for ; Tue, 3 Aug 2004 22:57:46 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsC1Z-0007S7-Hb for dhcwg@ietf.org; Tue, 03 Aug 2004 23:01:07 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i742uk104477; Wed, 4 Aug 2004 05:56:46 +0300 Date: Wed, 4 Aug 2004 05:56:45 +0300 (EEST) From: Pekka Savola To: Bernie Volz Subject: RE: [dhcwg] Trust model of Client FQDN option In-Reply-To: <000c01c479bb$eba91af0$c3838182@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org, "'Ted Lemon'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, 3 Aug 2004, Bernie Volz wrote: > Correct, this appears in draft-ietf-dhc-ddns-resolution-07.txt. This draft > is referenced in the "7. DNS Update Conflicts" section of the FQDN draft. > > The resolution draft still needs additional work for DHCPv6 - it currently > only applies to IPv4. This has some, but relatively little, to do with "Resolution of DNS Name Conflicts among DHCP Clients", because the main threat is that it doesn't conflict with another *DHCP client* (though that's imaginable as well) but a manual entry (or that it might not conflict at all, but just be something like wwww.example.com (with one extra 'w'). In any case, I think this requires quite a bit more extensive discussion (and appropriate pointers) in draft-ietf-dhc-fqdn-option (which seems like the main draft of this bundle) especially from the *security* perspective. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 23:54:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08199; Tue, 3 Aug 2004 23:54:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCkd-0004CX-15; Tue, 03 Aug 2004 23:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCjj-00045C-Cp for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 23:46:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07763 for ; Tue, 3 Aug 2004 23:46:40 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsCmu-00089R-Ol for dhcwg@ietf.org; Tue, 03 Aug 2004 23:50:02 -0400 Received: from [66.93.162.248] (0127bhost242.starwoodbroadband.com [12.105.247.242]) by toccata.fugue.com (Postfix) with ESMTP id A3BB31B23A9; Tue, 3 Aug 2004 22:45:47 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option Date: Tue, 3 Aug 2004 20:46:34 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 4:05 PM, Pekka Savola wrote: > The actual meat is missing, and does not address *DNS name* > authorization at all, just talks quite a bit about DHCP authentication > and different ways to eliminate DHCP spoofing. The meat isn't missing. It's just in the draft that defines how the server is supposed to do it. There is a normative reference to that draft in the FQDN draft. The FQDN draft defines the format of the FQDN option and what the bits in it mean. The reason they're in two separate drafts is that the IESG asked us to split the draft describing how DHCP does DNS updates into three drafts - one to describe the DNS RRtype, one to describe the DHCP option, and one to describe their interaction. Are you now asking that we merge the three drafts (actually, it's grown to five!) back into one? As for your question about names that are _already_ in the DNS, this is addressed in the DNS name conflict resolution draft (and has been addressed in that draft for six years, and was addressed in the joint draft before the draft was split into three). I also addressed it in the email to which you are replying. I would like to encourage you to read these drafts, in their current versions, thoroughly. If you have specific changes you would like to suggest, please suggest them. Include the wording you would like changed, removed, or added. Please make sure that your suggestions address the set of drafts, not just one specific draft. For example, if you don't feel that the FQDN draft adequately clues the reader in to the fact that they need to read the conflict resolution draft, suggest the wording you would like us to add to address that problem. Otherwise it's impossible to make forward progress - we either have to declare consensus without you, or not advance the drafts, and neither of these choices is desirable. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 23:57:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08394; Tue, 3 Aug 2004 23:57:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCsB-0005TS-ND; Tue, 03 Aug 2004 23:55:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCnl-0004is-Mi for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 23:50:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08050 for ; Tue, 3 Aug 2004 23:50:51 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsCqy-0008EX-K5 for dhcwg@ietf.org; Tue, 03 Aug 2004 23:54:12 -0400 Received: from [66.93.162.248] (0127bhost242.starwoodbroadband.com [12.105.247.242]) by toccata.fugue.com (Postfix) with ESMTP id D308D1B23A9; Tue, 3 Aug 2004 22:50:01 -0500 (CDT) In-Reply-To: <4.3.2.7.2.20040803194603.026f35b0@goblet.cisco.com> References: <0I1W003M40D71R@ms3.samsung.com> <0I1W003M40D71R@ms3.samsung.com> <4.3.2.7.2.20040803194603.026f35b0@goblet.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <793668A1-E5C9-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 20:50:49 -0700 To: Kim Kinnear X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 4:55 PM, Kim Kinnear wrote: > I strongly believe that saying that a DHCP server MUST > NOT send this option unless a client requests it is very > much not the way to achieve this end. This will require > special case code in every DHCP server which wants to be > compliant with this draft (and future RFC). I see this > as a "cure worse than the disease". How about making it a SHOULD NOT? I don't really want to add a special case to my server to do this either, but I do want there to be strong language there about it. I agree that it's really a client requirement, and that we should say what we really want, but I have found that client implementors quite frequently only skim the spec, so it'd be nice if there were two places where they could read something that would make them want to do the right thing, and not just one such place. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 00:04:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09057; Wed, 4 Aug 2004 00:04:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCzI-0006bm-Ft; Wed, 04 Aug 2004 00:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCu1-0005oR-0z for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 23:57:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08392 for ; Tue, 3 Aug 2004 23:57:18 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsCxC-0008Lo-VX for dhcwg@ietf.org; Wed, 04 Aug 2004 00:00:40 -0400 Received: from [66.93.162.248] (0127bhost242.starwoodbroadband.com [12.105.247.242]) by toccata.fugue.com (Postfix) with ESMTP id 62B061B2A7A; Tue, 3 Aug 2004 22:56:28 -0500 (CDT) In-Reply-To: <001401c479be$e1045080$c3838182@amer.cisco.com> References: <001401c479be$e1045080$c3838182@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5FC8251E-E5CA-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 20:57:16 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 6:03 PM, Bernie Volz wrote: > I haven't checked and don't recall, but do you know whether existing > clients > generally include it in the PRL today? Some do, some don't. There's special case in the ISC and Nominum DHCP servers to override the parameter request list in this case, and the code is there because of customer complaints, not because we just thought it might be useful. :') I think it's a lost cause trying to retrieve things with the FQDN option for DHCPv4. I think we were careful in RFC3315 to specify the meaning of the ORO unambiguously, but it might still be nice to mention that the mere presence of the FQDN option in the message to the server does not override the ORO, and that if the client doesn't list the FQDN option in the ORO, it will not get one back from the server. BTW, it's actually useful in the case of the FQDN option to _not_ include it in the ORO - most DHCP clients probably don't _care_ whether the server did the update. They want to tell the server what they'd like done, but if the server doesn't do the update, nothing about the client's behavior is likely to change. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 00:26:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09962; Wed, 4 Aug 2004 00:26:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsDId-0001Y5-LJ; Wed, 04 Aug 2004 00:22:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsDFK-0001Eu-HX for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 00:19:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09683 for ; Wed, 4 Aug 2004 00:19:19 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsDIW-0000Nn-QP for dhcwg@ietf.org; Wed, 04 Aug 2004 00:22:42 -0400 Received: from [66.93.162.248] (0127bhost242.starwoodbroadband.com [12.105.247.242]) by toccata.fugue.com (Postfix) with ESMTP id F199E1B22D8 for ; Tue, 3 Aug 2004 23:18:29 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <5FC8251E-E5CA-11D8-8860-000A95D9C74C@nominum.com> References: <001401c479be$e1045080$c3838182@amer.cisco.com> <5FC8251E-E5CA-11D8-8860-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73886984-E5CD-11D8-8860-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 21:19:17 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hm, let me be more clear about one thing. I agree that it makes intuitive sense that if you have a two-way option, you needn't mention it in the ORO. However, this makes implementation potentially more complicated, particularly in DHCPv6. So I think there's some real value in just requiring that any option the client wants to get back should be specified in the ORO, rather than having some options where you have to ask for them in the ORO, and some options where you do not. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 08:33:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01374; Wed, 4 Aug 2004 08:33:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsKug-0007Hm-Pu; Wed, 04 Aug 2004 08:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsKoE-0006fZ-AX for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 08:23:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01015 for ; Wed, 4 Aug 2004 08:23:53 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsKrU-0007Mr-W6 for dhcwg@ietf.org; Wed, 04 Aug 2004 08:27:18 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i74CNknv001486; Wed, 4 Aug 2004 07:23:47 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i74CNjF13579; Wed, 4 Aug 2004 08:23:45 -0400 (EDT) From: Joe Quanaim To: Ted Lemon , JINMEI Tatuya / =?iso-2022-jp?q?=1B$B=3F=40L=40C#=3AH=1B=28B?= Subject: Re: [dhcwg] one more comment about the lifetime option Date: Wed, 4 Aug 2004 08:21:23 -0400 User-Agent: KMail/1.5.4 References: <72FA02EA-E599-11D8-8860-000A95D9C74C@nominum.com> In-Reply-To: <72FA02EA-E599-11D8-8860-000A95D9C74C@nominum.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408040820.24319.jdq@lucent.com> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Stig.Venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Ted Lemon wrote: > On Aug 3, 2004, at 10:03 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > > Is it possible to specify different lifetimes for different instances > > of stateless information? For example, people may want to specify > > different lifetimes for recursive DNS server addresses and for SIP > > server addresses. > > I think the amount of work the server has to do to make this happen is > more than the amount of work that is saved. That is, you're going to > have to process an Information Request packet every time anything on > the client expires. And figuring out that you only need to send > certain options, and not certain others, is more work than just sending > what you have. So I think that not only is it not necessary to have > different lifetimes for different options, it's actually harmful to > have them. Per option lifetimes also make client implementations more complicated. Furthermore, they have the potential to cause more dhcpv6 traffic for everyone. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:31:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16101; Wed, 4 Aug 2004 12:31:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGT-0004ku-Q9; Wed, 04 Aug 2004 12:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5mt-0005sG-Qz for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:21:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08934 for ; Tue, 3 Aug 2004 16:21:30 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs5q1-0000gW-GI for dhcwg@ietf.org; Tue, 03 Aug 2004 16:24:47 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 13:21:19 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:21:16 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:21:15 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:21:00 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 13:20:54 -0700 Message-ID: Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR33nZY3AAj1fryQ0q7L/pvAa0hpwBqpQUQ From: "Dave Thaler" To: , X-OriginalArrivalTime: 03 Aug 2004 20:21:00.0547 (UTC) FILETIME=[64729530:01C47997] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400 Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'll put the larger meta issues in this message, and the specific technical comments on the draft in a separate message. I pretty much agree with Pekka's comments. We have a proposed standard protocol (MADCAP) that does everything this draft can, but is more complex. The main question is whether there is sufficient justification to create another slightly better way of doing the same thing? Two types of issues that are not relevant: * Config issues, since MADCAP admin can be (and is) integrated with DHCP, and the set of things to configure/administer is unchanged in this proposal. * Application API issues, since this is again the same between MADCAP and this draft. Complexity issues ARE relevant. MADCAP was designed to be able to share database-type code with a DHCP implementation, but=20 parsing-type code is different. This draft doesn't require=20 parsing-type code to be different (other than a couple new=20 options). Let's first recall a bit of history to see where we're at today: >From minutes of December 1998 IETF (http://www.icir.org/malloc/minutes.98.12.html), there was a survey of DHCP implementers, regarding MADCAP (formerly known as MDHCP): 5 DHCP implementors responded.=20 Do you think that you might implement an MDHCP client or server? 3 Yes, 1 will accept mods, 1 if there's demand=20 If you were to do so, would you attempt to share code with your DHCP client or server?=20 3 Yes, 1 Maybe, 1 Little=20 Do you think that we should continue to maintain a similarity between MDHCP and DHCP?=20 3 Yes, 1 No Opinion, 1 Do The Right Thing Now we have at least 2 implementations of MADCAP (Windows and Linux) for IPv4, but no implementations of MADCAP that I'm aware of for IPv6 (yes the RFC covers both). However, although there have been deployments, we have not seen lots of deployments of it. If there were major blocking issues specific to the protocol, one would think the current implementers would be aware of them. Instead, there is just lack of customer demand. =20 Next, what has changed in the world between 1998 and 2004? 1) We have SSM, and the majority of the application drivers of multicast usage fit into that model. This reduces the need for anything new in this space, since both MADCAP and this draft are specific to ASM. 2) The expectation that interdomain multicast will become ubiquitous has gone down somewhat. Again this reduces the need for anything in this space. 3) We have Unicast-Prefix-Based Multicast Addresses for IPv6. This reduces=20 again the need for server-based allocation, since techniques on a LAN may be used instead (like random allocation, or perhaps something like ZMAAP). 4) Because multicast connectivity is not ubiquitous, application-layer multicast solutions and infrastructures are now common. This again reduces the demand for IP multicast to cases with efficiency issues, such as those with a huge number of receivers, which is often the same class of applications wanting SSM. 5) MADCAP implementations are available. 6) DHCPv6 implementations are available. Is there anything above that would suggest that creating another solution would be sufficient to generate more customer demand? At the moment, I'm not seeing it, even taking #6 into account, and so this is the first question that needs to be answered before committing to invest significant effort. Are we just hoping that if the widget is painted green instead of red, that people will buy it because green is a nicer color and green means go? Or is the color not that important because it's still just a widget? =20 Next question: do we expect ASM to be deployed in a given network a) not at all b) only for IPv6 c) for both IPv4 and IPv6 d) only for IPv4 If (a) or (d), then this draft is moot. =20 If (b), then this draft is nice. If (c), then there's one argument that the same solution should be used for both IPv4 and IPv6 to provide consistency and ease of management (admins don't have to learn two different things). MADCAP was designed for this, whereas DHCPv4 can't be used. Hence this argues that MADCAP is a better fit for (c). Final high-level point: the draft states that DHCPv6 is expected to be widely deployed, which I agree with. However, the use of DHCPv6 for address allocation will be less widely deployed. In an environment using stateless addr conf for address allocation, some of the reasons why the DHCPv6 solution is desirable go away, since the mechanism will be new to the admins regardless of whether one uses existing MADCAP or new DHCPv6 stuff.=20 -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:32:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16250; Wed, 4 Aug 2004 12:32:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGU-0004kz-4I; Wed, 04 Aug 2004 12:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs627-0007T3-Nw for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10084 for ; Tue, 3 Aug 2004 16:37:13 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs65E-0000x3-MK for dhcwg@ietf.org; Tue, 03 Aug 2004 16:40:31 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 13:36:40 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:37:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:36:51 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:36:04 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 13:36:38 -0700 Message-ID: Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR4eCq1jb72togVQ56ZwYkNOtjSkABH2Tog From: "Dave Thaler" To: , X-OriginalArrivalTime: 03 Aug 2004 20:36:04.0753 (UTC) FILETIME=[7F657810:01C47999] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400 Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Two technical issues on this draft (larger issues sent in separate email): 1) One of the things that both the API and the MADCAP protocol provide is allocation of ranges (not "several", but a large number of addresses, like a block of 400). This requirement came from applications which want a larger range to use with things like=20 a) hashing resource ids into groups (I can't remember the specific examples here, but IANA often gets requests for blocks of space, and I believe many of them are for this reason. Dave Meyer can probably correct me :), b) assignment to areas inside virtual worlds (from customers in the DIS industry),=20 etc. =20 These sorts of applications are also the ones most in need of IPv6 multicast instead of IPv4 multicast, and so the requirement is probably even more compelling in IPv6. 2) Another thing that both the API and the MADCAP protocol provide is the ability to enumerate scopes (specifically, human readable names for them, and TTLs/HopCounts to use with them). The names for scopes are also useful in other contexts besides multicast address allocation. (E.g., see discussion of http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options- 01.txt at http://www.ietf.org/proceedings/03jul/139.htm, has also come up in MMUSIC, etc.) Hence this capability should be retained. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:33:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16362; Wed, 4 Aug 2004 12:33:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGU-0004l6-HC; Wed, 04 Aug 2004 12:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs68I-0008RD-SR for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:43:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10459 for ; Tue, 3 Aug 2004 16:43:36 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6BQ-00013C-PV for dhcwg@ietf.org; Tue, 03 Aug 2004 16:46:54 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 13:43:02 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:43:07 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:43:10 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:42:29 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 13:43:02 -0700 Message-ID: Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR38/lR3lZjfTTTTAiSTPKTdARmZQBpbokA From: "Dave Thaler" To: "Stig Venaas" , "Pekka Savola" X-OriginalArrivalTime: 03 Aug 2004 20:42:29.0110 (UTC) FILETIME=[647DB160:01C4799A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Stig Venaas writes: > On Sun, Aug 01, 2004 at 06:03:48PM +0300, Pekka Savola wrote: > [...] > > have RFC3306 or embedded-RP; it is not clear which problem we're solving > > (and which problems remain to be solved). > > > > In particular, if any host on a link with a /64 prefix could calculate > its > > own multicast prefix (unique to that link) on its own, and have 32 bits > of > > group-id's to pick from (making sure they don't conflict on that link), > > could one argue that there is no need for central multicast address > > assignment.. but rather a mechanism where the host could pick a group-id > in > > such a way it doesn't conflict (a random process should be sufficient, > but > > if not, there could be Multicast DAD)? >=20 > Yes, I've also thought a bit about this. The 64-bit link-id could be a > starting point too. I think some form of DAD would be nice.=20 The "multicast DAD" functionality is what ZMAAP was proposed for in the Zeroconf WG, but it expired due to lack of interest at the time. It's at http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:33:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16433; Wed, 4 Aug 2004 12:33:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGU-0004lB-R3; Wed, 04 Aug 2004 12:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6W4-0003U8-9P for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 17:08:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12125 for ; Tue, 3 Aug 2004 17:08:10 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6ZC-0001TN-Ha for dhcwg@ietf.org; Tue, 03 Aug 2004 17:11:27 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 14:08:03 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 14:07:31 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 14:07:43 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 14:07:02 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 14:07:36 -0700 Message-ID: Thread-Topic: Comments on draft-ietf-dhc-dual-stack-01 thread-index: AcR4eCq1jb72togVQ56ZwYkNOtjSkABH2TogAAEk7GA= From: "Dave Thaler" To: X-OriginalArrivalTime: 03 Aug 2004 21:07:02.0960 (UTC) FILETIME=[D2F95B00:01C4799D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400 Subject: [dhcwg] Comments on draft-ietf-dhc-dual-stack-01 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable This draft is still missing a discussion of one of the issues that has been raised a couple times in the past, including during the WG discussion of this draft last IETF. Specifically, the issue occurs with any option that includes a list of addresses of servers (e.g., DNS server addresses). The reason for having a list in the first place is to allow the client to try an alternate address in the event that the first one it tries fails. When such a failure occurs, it may be for either of two reasons: a) The server has failed b) Connectivity via IPv4 or IPv6 has failed When you have a set of dual-stack servers and dual-stack clients, and the first attempt fails, to maximize the chance that the next attempt will succeed in the absence of being able to distinguish between (a) and (b), the client should try a different server, via a different protocol. The problem today is that you get the IPv4 list via DHCPv4 and the IPv6 list via DHCPv6, and the client has no way to really "try a different server", since that information is lost by the protocol, even though it may be known by the server. Just putting merging heuristics in the client cannot provide the best behavior, since information is lost. By comparison, if IPv4-mapped addresses were included in the DHCPv6 option along with IPv6 addresses, the DHCP server can give an intelligent order that takes into account which addresses are of the same DNS/whatever server. Of course, v6-only clients have to know to discard the v4-mapped addresses in this solution, and it's much easier to solve this in the combined-DHCP-server case than in the two-server case. I believe this draft needs to discuss this dual-stack issue and its implications. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:48:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17889; Wed, 4 Aug 2004 12:48:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOiM-0000Sc-3O; Wed, 04 Aug 2004 12:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOSF-0007uQ-JH for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 12:17:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14756 for ; Wed, 4 Aug 2004 12:17:24 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsOVX-0002R3-QL for dhcwg@ietf.org; Wed, 04 Aug 2004 12:20:53 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i74GHJnE028527 for ; Wed, 4 Aug 2004 17:17:19 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA18510 for ; Wed, 4 Aug 2004 17:17:15 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i74GHFO15594 for dhcwg@ietf.org; Wed, 4 Aug 2004 17:17:15 +0100 Date: Wed, 4 Aug 2004 17:17:15 +0100 From: Tim Chown To: dhcwg@ietf.org Message-ID: <20040804161715.GF14984@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [dhcwg] IETF DHC Jabber log 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Is at: http://www.xmpp.org/ietf-logs/dhc@ietf.xmpp.org/2004-08-03.html tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 13:15:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19963; Wed, 4 Aug 2004 13:15:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPHv-0000Zk-C5; Wed, 04 Aug 2004 13:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPAV-0007QW-25 for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:03:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18980 for ; Wed, 4 Aug 2004 13:03:08 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPDo-0003f2-4C for dhcwg@ietf.org; Wed, 04 Aug 2004 13:06:37 -0400 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:89a7:e1ff:1445:7453]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 123051525D; Thu, 5 Aug 2004 02:03:01 +0900 (JST) Date: Thu, 05 Aug 2004 02:03:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> References: <20040803171447.GA27805@sverresborg.uninett.no> <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 03 Aug 2004 13:59:10 -0400, >>>>> Ralph Droms said: > I agree with Stig - we've discussed this issue before and come to the > conclusion that there is little extra overhead in delivering information > that has not changed, so there should be a single lifetime - chosen to be > the shortest lifetome of any of the client's parameters. Okay, I'm fine with the "singe lifetime for all option parameters" approach. In fact, I was just wondering without any particular preference. But I want the document to be more specific on this point because other readers might wonder the same point. 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 Aug 4 13:34:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21604; Wed, 4 Aug 2004 13:34:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPUo-0002pY-S0; Wed, 04 Aug 2004 13:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPNe-0001ag-MI for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:16:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20100 for ; Wed, 4 Aug 2004 13:16:43 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPQy-0003xB-Qi for dhcwg@ietf.org; Wed, 04 Aug 2004 13:20:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2004 10:17:58 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i74HGCDZ019489; Wed, 4 Aug 2004 10:16:12 -0700 (PDT) Received: from volzw2k (sjc-vpn3-189.cisco.com [10.21.64.189]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKP36098; Wed, 4 Aug 2004 13:16:10 -0400 (EDT) From: "Bernie Volz" To: "'Pekka Savola'" Subject: RE: [dhcwg] Trust model of Client FQDN option Date: Wed, 4 Aug 2004 13:17:37 -0400 Organization: Cisco Message-ID: <002101c47a46$f10e92a0$3f428182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "'Ted Lemon'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi: Ok, perhaps that title of the draft isn't the greatest, but see section 6.3.1: 6.3.1 Initial DHCID RR Query When a DHCP client or server intends to update an A RR, it performs a DNS query with QNAME of the target name and with QTYPE of DHCID. If the query returns NXDOMAIN, the updater can conclude that the name is not in use and proceeds to Section 6.3.2. -> If the query returns NODATA, the updater can conclude that the target -> name is in use, but that no DHCID RR is present. This indicates that -> some records have been configured by an administrator. Whether the -> updater proceeds with an update is a matter of local administrative -> policy. Now, admittedly doesn't address the situation where there is no existing "www" name and a client comes along and requests to use that. If you have a better name suggestion for the draft, please let me know. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Pekka Savola > Sent: Tuesday, August 03, 2004 10:57 PM > To: Bernie Volz > Cc: dhcwg@ietf.org; 'Ted Lemon' > Subject: RE: [dhcwg] Trust model of Client FQDN option > > > On Tue, 3 Aug 2004, Bernie Volz wrote: > > Correct, this appears in > draft-ietf-dhc-ddns-resolution-07.txt. This > > draft is referenced in the "7. DNS Update Conflicts" > section of the > > FQDN draft. > > > > The resolution draft still needs additional work for DHCPv6 - it > > currently only applies to IPv4. > > This has some, but relatively little, to do with "Resolution > of DNS Name Conflicts among DHCP Clients", because the main > threat is that it doesn't conflict with another *DHCP client* > (though that's imaginable as well) but a manual entry (or > that it might not conflict at all, but just be something like > wwww.example.com (with one extra 'w'). > > In any case, I think this requires quite a bit more extensive > discussion (and appropriate pointers) in > draft-ietf-dhc-fqdn-option (which seems like the main draft > of this bundle) especially from the > *security* perspective. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > 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 Aug 4 13:41:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22204; Wed, 4 Aug 2004 13:41:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPf5-00056s-GP; Wed, 04 Aug 2004 13:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPWZ-0003F0-RH for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:26:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20993 for ; Wed, 4 Aug 2004 13:25:58 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPZs-00049h-PG for dhcwg@ietf.org; Wed, 04 Aug 2004 13:29:26 -0400 Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id 73E491B2219; Wed, 4 Aug 2004 12:25:00 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Wed, 4 Aug 2004 10:25:54 -0700 To: "Dave Thaler" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Dave, I think probably the overriding issue that's prevented there from being more widespread implementation of MADCAP is that the internet routing infrastructure doesn't support multicast. So there aren't any customers. So nobody comes banging on our door asking for MADCAP. So there's minimal implementation of MADCAP. I would say that it was a chicken-and-egg problem except that I think that if there were routing infrastructure, people would do multicast even if there were no MADCAP. So this isn't really an obstacle to implementation - it's something that would be nice to have if only there were a place to use it. The proposal on the table is simpler than MADCAP, not more complicated. It might be possible to implement even if there is low demand, where MADCAP, which is a bit fancier, isn't going to get implemented unless there is high demand. So the way I would frame this issue is, if we implement the proposal, does that prevent deployment of MADCAP later when there's enough demand to support widespread implementation of MADCAP. I think the answer is no. And does implementing this help people who are trying to solve the real problems in the multicast world to make forward progress? Apparently some think yes - I have no opinion since I'm not a multicast guy myself. Finally, is it likely that people could justify implementing this who can't yet justify implementing MADCAP? TBF, I don't know. It does look easier to me, but it still requires significant code changes. Following this line of reasoning, I have to say that I'm tempted to ask the authors to consider whether or not they can make this even simpler. Do we really need a new IA type, or can we do this with a regular IA and an option? The reason I ask is that picking which address allocation pool to use based on an option is well-understood technology - I think probably every DHCP server vendor already knows how to do this. And I don't think there are any particularly special constraints on how address allocation will be done for multicast addresses - you still just pick one out of a pool. So I think you can go cheaper on this, and maybe it would feel less like we were trying to come up with another MADCAP, which doesn't seem like the right thing to do. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 13:43:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22547; Wed, 4 Aug 2004 13:43:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPf9-00059h-Rd; Wed, 04 Aug 2004 13:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPZi-0003wY-72 for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:29:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21241 for ; Wed, 4 Aug 2004 13:29:12 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPd2-0004Ek-Ac for dhcwg@ietf.org; Wed, 04 Aug 2004 13:32:40 -0400 Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id B39A11B22FD; Wed, 4 Aug 2004 12:28:15 -0500 (CDT) In-Reply-To: References: <20040803171447.GA27805@sverresborg.uninett.no> <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Re: one more comment about the lifetime option Date: Wed, 4 Aug 2004 10:29:09 -0700 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 4, 2004, at 10:03 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > But I want the document to be more specific on this point because > other readers might wonder the same point. Yes, if there was a question for you, there will be questions for others, and this needs to be clarified. I think we're just debating (well, for once, resoundingly agreeing on) what the clarification should be. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 13:52:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23406; Wed, 4 Aug 2004 13:52:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPsm-0007Pd-Dn; Wed, 04 Aug 2004 13:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPjz-0005qy-IR for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:39:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22155 for ; Wed, 4 Aug 2004 13:39:50 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPnG-0004S5-Q9 for dhcwg@ietf.org; Wed, 04 Aug 2004 13:43:18 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 4 Aug 2004 10:39:26 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 10:39:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 10:39:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 4 Aug 2004 10:38:59 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 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] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Wed, 4 Aug 2004 10:39:09 -0700 Message-ID: Thread-Topic: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR6SBfZhgW4MGcfTVezxeInAQhuCgAAFRfA From: "Dave Thaler" To: "Ted Lemon" X-OriginalArrivalTime: 04 Aug 2004 17:38:59.0513 (UTC) FILETIME=[ECAC4290:01C47A49] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted Lemon writes: > Dave, I think probably the overriding issue that's prevented there from > being more widespread implementation of MADCAP is that the internet > routing infrastructure doesn't support multicast. So there aren't any > customers. So nobody comes banging on our door asking for MADCAP. > So there's minimal implementation of MADCAP. Right. That's my point precisely. The blocker is not really the complexity of the protocol, that's a secondary issue. > I would say that it was a chicken-and-egg problem except that I think > that if there were routing infrastructure, people would do multicast > even if there were no MADCAP. So this isn't really an obstacle to > implementation - it's something that would be nice to have if only > there were a place to use it. Right. > The proposal on the table is simpler than MADCAP, not more complicated. We're in complete agreement here (for IPv6), I said the same thing in my email. > It might be possible to implement even if there is low demand, where > MADCAP, which is a bit fancier, isn't going to get implemented unless > there is high demand. So the way I would frame this issue is, if we > implement the proposal, does that prevent deployment of MADCAP later > when there's enough demand to support widespread implementation of > MADCAP. I think the answer is no. =20 Agree, although I think there's little reason to implement MADCAP for IPv6 if you implement DHCPv6 for multicast. > And does implementing this help > people who are trying to solve the real problems in the multicast world > to make forward progress? Apparently some think yes - I have no > opinion since I'm not a multicast guy myself.=20 This is the part I'm pushing on. This proposal only solves a problem if you have V6-only multicast (which is indeed the case in the research network which motivated this proposal). I'm asking the WGs whether there's real customer demand for any-source multicast, which was the issue at the top of this email, as well as whether the demand would be for v6-only or for v4/v6 both. If folks want a v4 solution as well, they'll do MADCAP, in which case the incremental complexity of adding IPv6 support is negligible. Just making a simpler solution that's IPv6-only doesn't necessarily mean anyone will use it, and I believe we should only spend IETF cycles on things that people will use. -Dave > Finally, is it likely > that people could justify implementing this who can't yet justify > implementing MADCAP? TBF, I don't know. It does look easier to me, > but it still requires significant code changes. >=20 > Following this line of reasoning, I have to say that I'm tempted to ask > the authors to consider whether or not they can make this even simpler. > Do we really need a new IA type, or can we do this with a regular IA > and an option? The reason I ask is that picking which address > allocation pool to use based on an option is well-understood technology > - I think probably every DHCP server vendor already knows how to do > this. And I don't think there are any particularly special > constraints on how address allocation will be done for multicast > addresses - you still just pick one out of a pool. So I think you can > go cheaper on this, and maybe it would feel less like we were trying to > come up with another MADCAP, which doesn't seem like the right thing to > do. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 13:55:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23574; Wed, 4 Aug 2004 13:55:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPsv-0007Tm-JQ; Wed, 04 Aug 2004 13:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPnO-0006P2-CU for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:43:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22471 for ; Wed, 4 Aug 2004 13:43:21 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPqh-0004X5-LN for dhcwg@ietf.org; Wed, 04 Aug 2004 13:46:49 -0400 Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id 9F1041B2219; Wed, 4 Aug 2004 12:42:23 -0500 (CDT) In-Reply-To: <002101c47a46$f10e92a0$3f428182@amer.cisco.com> References: <002101c47a46$f10e92a0$3f428182@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option Date: Wed, 4 Aug 2004 10:43:16 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 4, 2004, at 10:17 AM, Bernie Volz wrote: > -> If the query returns NODATA, the updater can conclude that the > target > -> name is in use, but that no DHCID RR is present. This indicates > that > -> some records have been configured by an administrator. Whether the > -> updater proceeds with an update is a matter of local administrative > -> policy. Hm, this is interesting. As a point of information, the two implementations with which I am familiar do not give the administrator a knob to tweak here. We just assume that if the name is in the DNS and doesn't have a DHCID (well, TXT) record, we shouldn't scribble on it. I think a stronger statement here might be better: Whether the updater proceeds with an update is a matter of local administrative policy. DHCP servers MUST NOT proceed with the update unless explicitly configured to do so. The draft should talk about these two issues in the security considerations section, and the FQDN drafts should mention in the security considerations section that these security considerations are addressed in the resolution draft. I don't think we can make any requirements to address this, but the answers we came up with in response to Pekka's query could reasonably go into the security considerations section of one or all of the drafts: 1. If the DHCP server does updates, there is no way to prevent one client from getting a name after another client had it, but that client's lease expired. 2. If the DHCP server does updates, it will be possible for DHCP clients to request names that might have special meaning, like www or wwww. This can be handled in one of two ways: a. Use a special zone for dynamic names, so that it doesn't matter that the client gets www.dyndns.bigcompany.org, or b. If the DHCP server provides this capability, set up a filter on the DHCP server that prevents certain names from being claimed by clients, even if they do not currently appear in the DNS. 3. If the DHCP server does updates, and is allowed to override names that do not have DHCID records, this can mean that a client will get a name that is already registered for some purpose in the DNS. This behavior is required to be disabled by default, so it should not be a problem in practice, but we mention it here to raise awareness of the implications of configuring your DHCP server to allow it. Hm, one other problem that occurs to me is that a client could send something like "www.students" in the fqdn option, and this could turn into "www.students.littlecollege.edu". That is a vaguely official-looking name. So any filtering that needs doing based on specific reserved names like "www" needs to be on the first label in the name, not on the entire name. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 14:18:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25560; Wed, 4 Aug 2004 14:18:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQ6n-0001gt-QB; Wed, 04 Aug 2004 14:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPz8-0000az-6z for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:55:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23571 for ; Wed, 4 Aug 2004 13:55:29 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQ2R-0004nU-JK for dhcwg@ietf.org; Wed, 04 Aug 2004 13:58:57 -0400 Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id 5E65F1B2273; Wed, 4 Aug 2004 12:54:31 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75E6FC93-E63F-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Wed, 4 Aug 2004 10:55:24 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 4, 2004, at 10:39 AM, Dave Thaler wrote: > I'm asking the WGs whether > there's real > customer demand for any-source multicast, which was the issue at the > top > of this email, as well as whether the demand would be for v6-only or > for > v4/v6 both. If folks want a v4 solution as well, they'll do MADCAP, in > which case > the incremental complexity of adding IPv6 support is negligible. Yup. I'd really like to have any-source multicast, because it would require a narrower pipe than the one I have to buy right now to do VoIP broadcasts to Regular Folks [tm]. And I don't think I'm alone in this. So there is customer demand at the bottom of the food chain. Unfortunately, I haven't seen any customer demand higher up the food chain than that. And of course, times being what they are, I want IPv4, but otoh I'm hoping that multicast might grow up in the IPv6 infrastructure, so my real hopes for some day having multicast rest on IPv6, not IPv4. So a v6-only solution isn't what I want, but it is what I think I can get. It's a complicated issue. I think that if there are some researchers who want a DHCPv6 option to use to do some research and that they'd like to deploy, it's okay for them to advance a document that describes that option, as long as it really gets them some traction. I think advancing a significant extension to the DHCP protocol probably isn't as good of an idea, given that MADCAP already does something similar. But the best really is the enemy of good enough, and I don't think we should completely poo-poo legitimate useful work that's being done just because there's a complex and wonderful alternative. I guess my point is that I would support doing a DHCP option for this if the mboned working group wants it, but I think that your concern is legitimate in the case where we are talking about something more involved than a DHCP option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 14:42:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27612; Wed, 4 Aug 2004 14:42:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQQN-0005Rp-3H; Wed, 04 Aug 2004 14:23:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQKo-0004Hr-7b for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 14:17:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25485 for ; Wed, 4 Aug 2004 14:17:52 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQO7-0005GQ-Pf for dhcwg@ietf.org; Wed, 04 Aug 2004 14:21:21 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2004 11:19:05 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i74IHGSK013153; Wed, 4 Aug 2004 11:17:17 -0700 (PDT) Received: from volzw2k (sjc-vpn4-15.cisco.com [10.21.80.15]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKP42380; Wed, 4 Aug 2004 14:17:16 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" Subject: RE: [dhcwg] Trust model of Client FQDN option Date: Wed, 4 Aug 2004 14:18:41 -0400 Organization: Cisco Message-ID: <000201c47a4f$78a634e0$3f428182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit And, we probably should add a 4th point ... If a DNS server allows dynamic DNS updates, it is the final authority of what it allows to be added, removed, or modified in a zone and should have properly configured policies to prohibit operations that are not intended. Simply assuming that any update from a trusted source (such as a DHCP server with a valid TSIG key) should be performed is likely not acceptable. - Bernie > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com] > Sent: Wednesday, August 04, 2004 1:43 PM > To: Bernie Volz > Cc: > Subject: Re: [dhcwg] Trust model of Client FQDN option > > > On Aug 4, 2004, at 10:17 AM, Bernie Volz wrote: > > -> If the query returns NODATA, the updater can conclude that the > > target > > -> name is in use, but that no DHCID RR is present. This indicates > > that > > -> some records have been configured by an administrator. > Whether the > > -> updater proceeds with an update is a matter of local > administrative > > -> policy. > > Hm, this is interesting. As a point of information, the two > implementations with which I am familiar do not give the > administrator > a knob to tweak here. We just assume that if the name is in the DNS > and doesn't have a DHCID (well, TXT) record, we shouldn't scribble on > it. > > I think a stronger statement here might be better: > > Whether the updater proceeds with an update is a matter of local > administrative policy. DHCP servers MUST NOT proceed with > the update > unless explicitly configured to do so. > > The draft should talk about these two issues in the security > considerations section, and the FQDN drafts should mention in the > security considerations section that these security > considerations are > addressed in the resolution draft. I don't think we can make any > requirements to address this, but the answers we came up with in > response to Pekka's query could reasonably go into the security > considerations section of one or all of the drafts: > > 1. If the DHCP server does updates, there is no way to prevent one > client from getting a name after another client had it, but that > client's lease expired. > > 2. If the DHCP server does updates, it will be possible for DHCP > clients to request names that might have special meaning, like www or > wwww. This can be handled in one of two ways: > a. Use a special zone for dynamic names, so that it doesn't > matter that the client gets www.dyndns.bigcompany.org, or > b. If the DHCP server provides this capability, set up a > filter on the DHCP server that prevents certain names from > being claimed by clients, even if they do not currently > appear in the DNS. > > 3. If the DHCP server does updates, and is allowed to override names > that do not have DHCID records, this can mean that a client > will get a > name that is already registered for some purpose in the DNS. This > behavior is required to be disabled by default, so it should not be a > problem in practice, but we mention it here to raise awareness of the > implications of configuring your DHCP server to allow it. > > Hm, one other problem that occurs to me is that a client could send > something like "www.students" in the fqdn option, and this could turn > into "www.students.littlecollege.edu". That is a vaguely > official-looking name. So any filtering that needs doing based on > specific reserved names like "www" needs to be on the first label in > the name, not on the entire name. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 15:49:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03671; Wed, 4 Aug 2004 15:49:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsRh4-0007nU-8J; Wed, 04 Aug 2004 15:44:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsRZb-0006U2-JE for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 15:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02777 for ; Wed, 4 Aug 2004 15:37:13 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsRcv-0006yh-Qp for dhcwg@ietf.org; Wed, 04 Aug 2004 15:40:43 -0400 Received: from [130.129.131.89] (opene-130-129-131-89.ietf60.ietf.org [130.129.131.89]) by toccata.fugue.com (Postfix) with ESMTP id AF56E1B22C7; Wed, 4 Aug 2004 14:36:14 -0500 (CDT) In-Reply-To: <000201c47a4f$78a634e0$3f428182@amer.cisco.com> References: <000201c47a4f$78a634e0$3f428182@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option Date: Wed, 4 Aug 2004 12:37:10 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 4, 2004, at 11:18 AM, Bernie Volz wrote: > And, we probably should add a 4th point ... If a DNS server allows > dynamic > DNS updates, it is the final authority of what it allows to be added, > removed, or modified in a zone and should have properly configured > policies > to prohibit operations that are not intended. Simply assuming that any > update from a trusted source (such as a DHCP server with a valid TSIG > key) > should be performed is likely not acceptable. I would expect this to be a rather controversial statement, and I think we should leave it out. It could be equally legitimately argued that if you give some entity a key to update a zone, you are trusting that entity not to do anything inappropriate with the key, and that if you do not trust that entity, you should not have given it such a key. I'm not saying either position is correct - they are both valid. So asserting one over the other seems like a recipe for delay. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 17:19:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09157; Wed, 4 Aug 2004 17:19:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsT20-0007yt-TY; Wed, 04 Aug 2004 17:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsSxU-0006lq-O9 for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 17:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08138 for ; Wed, 4 Aug 2004 17:05:58 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsT0q-0000AD-5x for dhcwg@ietf.org; Wed, 04 Aug 2004 17:09:28 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1X0013GX92H6@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 05 Aug 2004 06:05:27 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1X001PLX7IQ3@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 05 Aug 2004 06:04:31 +0900 (KST) Received: from ep_spt03 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1X00DFLX7I0K@ms3.samsung.com> for dhcwg@ietf.org; Thu, 05 Aug 2004 06:04:30 +0900 (KST) Content-return: prohibited Date: Wed, 04 Aug 2004 21:04:39 +0000 (GMT) From: PARK SOO HONG X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: dhcwg@ietf.org Message-id: <0I1X00DFMX7I0K@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20040804210420704@soohong.park X-MTR: 20040804210420704@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Score: 1.7 (+) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: [dhcwg] Fwd: Re: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0716083092==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0716083092== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

I am forwarding this mail since I missed dhcwg address.



------- Original Message -------
Sender : PARK SOO HONG<soohong.park@samsung.com> Engineer/Mobile Platform Lab/Samsung Electronics
Date : Aug 05, 2004 05:38
Title : Re: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels

Fred, which draft do yo mean ?

 

To avoid reader's confusion, I am writing this mail since current subject

(Automatic Configuration of IPv6-over-IPv4 Tunnels) is so ambiguous.

 

Regarding this issue, currently two drafts were proposed in this meeting

however the aspect of these draft is so different.

 

[1] DHCP Option for Configuring IPv6-over-IPv4 Tunnels <draft-daniel-dhc-ipv6in4-opt-04.txt>

Abstract:This document provides a mechanism by which the DHCPv4 servers can provide

information about the configured IPv6-over-IPv4 tunnel end-point. The IPv4/IPv6 dual-stack

nodes can use this information to set up a configured tunnel to the tunnel end-point to obtain

IPv6 connectivity.

 

[2]Configured Tunnel End-Point Configuration using DHCPv4 <draft-daniel-dhc-dhcpv4-tep-conf-01>

Abstract:The intent of this draft is to provide a solution to automate tunnel end-point configuration

for a configured IPv6-over-IPv4 tunnel. This uses a DHCPv4 option to percolate the tunnel

end-point configuration information. This is very useful to connect a newly deployed native

IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated

dual-stack IPv4/IPv6 nodes to IPv6 networks through IPv4.

 

Hope this helps...

 

PS:

As author of these draft, I am wondering how long time do I have to wait for the "symetric" ?

This means that I have to wait for the v6ops adoption of related drafts to be WG items ?

I think it is not smart reaction because these draft are for DHCP solutions. It means these

drafts do not mean all (perfect) solutions for discoverying IPv6-over-IPv4 tunnels.

 

Furthermore, I already received v6ops comments via mailing list on "draft-daniel-dhc-ipv6in4-opt-04.txt"

and tried to reflect gathered comments until now. In addition, as I said, my implementation is almost

done...Do I have to wait another v6ops comments again and again ? How long ?....

 

 

 

I believe this suggestion is better ...

"[11:49:40] <timchown> lemon: adopt this, get it ready to go, THEN hold until we release or get v6ops consensus"

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics



------- Original Message -------
Sender : Fred L. Templin<ftemplin@iprg.nokia.com>
Date : Aug 05, 2004 03:18
Title : Re: Automatic Configuration of IPv6-over-IPv4 Tunnels
I proposed a DHCPv4 option for tunnel endpoint discovery in an I-D
about 2 years ago, and the document was widely ignored. Why all of
a sudden this renewed interest? (Asked the other way around, why
was there no interest 2 years ago when the I-D was still active?)

Fred
ftemplin@iprg.nokia.com

Ralph Droms wrote:
> Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?).  We have 
> a request to fast track a DHCPv6 option for MIPv6 home agent options.  I 
> guess that's for 3GPP2, not 3GPP.  3GPP is not using DHCP at all?
> 
> - Ralph
> 
> At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote:
> 
>> Hi Syam,
>>
>> I think this is an interesting work, and should be continued within 
>> DHC WG.
>>
>> But I'm not sure will fit in the zeroconfiguration requirements, 
>> because for example in 3GPP DHCP is not being used.
>>
>> Anyway, we are already discussing this and will consider the option.
>>
>> But it could be feasible in ISP scenarios when only the own-ISP 
>> customers are the goal for providing a transition service.
>>
>> Regards,
>> Jordi
>>
>> ---- Original Message ----
>> From: "Syam Madanapalli" <smpalli@yahoo.com>
>> To: <v6ops@ops.ietf.org>
>> Sent: Wednesday, August 04, 2004 8:10 AM
>> Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels
>>
>> > Hello,
>> >
>> > We have a draft that propose a DHCPv4 Option for
>> > carrying Tunnel
>> > Informtion, so that the tunnels can be configured
>> > automatically
>> > between the IPv6 clouds seperated by v4 network.
>> >
>> > The intent of this draft is to provide a solution to
>> > automate tunnel
>> > end-point configuration for a configured
>> > IPv6-over-IPv4 tunnel. This
>> > uses a DHCPv4 option to distribute the tunnel
>> > end-point configuration
>> > information. This is very useful to connect a newly
>> > deployed native
>> > IPv6 cloud to other existing IPv6 networks using IPv4
>> > backbone as
>> > well as to connect isolated dual-stack IPv4/IPv6 nodes
>> > to IPv6 clouds
>> > through IPv4 Network.
>> >
>> > This draft proposesa DHCP option as well as a
>> > procedure to automate
>> > the bidirectional tunnel configuration.
>> >
>> > I am wondering if this fits into v6ops
>> > zeroconfiguration requirements
>> > for tunnel configuration. Any comments/suggestions
>> > welcome.
>> >
>> > PPT:
>> > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt
>> > Dradft:
>> > 
>> http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt 
>>
>> >
>> >
>> > Thank you,
>> > Syam
>> >
>> >
>> >
>> >
>> >
>> >
>> > __________________________________
>> > Do you Yahoo!?
>> > Yahoo! Mail - 50x more storage than other providers!
>> > http://promotions.yahoo.com/new_mail
>>
>>
>> **********************************
>> Madrid 2003 Global IPv6 Summit
>> Presentations and videos on line at:
>> http://www.ipv6-es.com
>>
>> This electronic message contains information which may be privileged 
>> or confidential. The information is intended to be for the use of the 
>> individual(s) named above. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the 
>> contents of this information, including attached files, is prohibited.
> 
> 
> 







 

 

 

 




 

 

 

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


--===============0716083092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0716083092==-- From dhcwg-bounces@ietf.org Wed Aug 4 18:26:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14681; Wed, 4 Aug 2004 18:26:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsU4o-0002cx-F0; Wed, 04 Aug 2004 18:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsTv4-0005iM-TM for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 18:07:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12455 for ; Wed, 4 Aug 2004 18:07:32 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsTyR-0001JA-Jp for dhcwg@ietf.org; Wed, 04 Aug 2004 18:11:03 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 4 Aug 2004 15:05:14 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 15:05:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 15:05:03 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 4 Aug 2004 15:04:42 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Aug 2004 15:03:10 -0700 Message-ID: Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR6blEdPChd+JtyS1yNAR0ROWUZ4AAAEL+w From: "Dave Thaler" To: "Jerome Durand" X-OriginalArrivalTime: 04 Aug 2004 22:04:42.0317 (UTC) FILETIME=[0B5317D0:01C47A6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable -----Original Message----- > From: Jerome Durand [mailto:jdurand@renater.fr] > Sent: Wednesday, August 04, 2004 6:01 AM > To: Dave Thaler > Cc: dhcwg@ietf.org; mboned@lists.uoregon.edu > Subject: Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 > comments >=20 > > 1) One of the things that both the API and the MADCAP protocol provide > > is > > allocation of ranges (not "several", but a large number of addresses, > > like > > a block of 400). This requirement came from applications which want a > > larger range to use with things like > > a) hashing resource ids into groups (I can't remember the specific > > examples here, but IANA often gets requests for blocks of space, and I > > believe many of them are for this reason. Dave Meyer can probably > > correct me :), > > b) assignment to areas inside virtual worlds (from customers in the DIS > > industry), >=20 > I don't beleive we really need this feature. A company that wants plenty > of addresses can be allocated manually for example a block. But can be > added to the specs. (prefix delegation for IPv6 multicast address could > be the answer) To be clear, this has nothing to do with company requests. This was about _application_ requests from the server's address space. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 19:36:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19621; Wed, 4 Aug 2004 19:36:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVG7-00028n-S4; Wed, 04 Aug 2004 19:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsTgu-0007zI-ID for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 17:52:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11251 for ; Wed, 4 Aug 2004 17:52:53 -0400 (EDT) Received: from mail1.renater.fr ([193.49.159.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsTkE-00011o-2c for dhcwg@ietf.org; Wed, 04 Aug 2004 17:56:25 -0400 Received: from 49.renater.fr ([193.49.159.49] helo=renater.fr) by mail1.renater.fr with esmtp (Exim 4.32) id 1BsTgC-0008IE-2J; Wed, 04 Aug 2004 23:52:13 +0200 Message-ID: <4110DC1B.9090208@renater.fr> Date: Wed, 04 Aug 2004 14:52:43 +0200 From: Jerome Durand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Spam-Report: Spam detection software, running on the system "mail1.renater.fr", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see postmaster@renater.fr for details. Content preview: > The "multicast DAD" functionality is what ZMAAP was proposed for in the > Zeroconf WG, but it expired due to lack of interest at the time. It's > at > http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt [...] Content analysis details: (0.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date X-Spam-Score: 0.6 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Aug 2004 19:33:22 -0400 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu, Stig Venaas , Pekka Savola Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > The "multicast DAD" functionality is what ZMAAP was proposed for in the > Zeroconf WG, but it expired due to lack of interest at the time. It's > at > http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt ZMAAP included many more things that just the multicast DAD. But it is right there was the idea of defending an address. There was no interest in the complete protocol (that was IMHO too much complex and not scalable). Jerome _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 19:37:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19951; Wed, 4 Aug 2004 19:37:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVG8-00028s-5g; Wed, 04 Aug 2004 19:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsToJ-0001aP-PU for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 18:00:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11653 for ; Wed, 4 Aug 2004 18:00:33 -0400 (EDT) Received: from mail1.renater.fr ([193.49.159.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsTrg-0001Bp-E9 for dhcwg@ietf.org; Wed, 04 Aug 2004 18:04:04 -0400 Received: from 49.renater.fr ([193.49.159.49] helo=renater.fr) by mail1.renater.fr with esmtp (Exim 4.32) id 1BsTnk-0008L9-Hu; Thu, 05 Aug 2004 00:00:01 +0200 Message-ID: <4110DDEF.4050601@renater.fr> Date: Wed, 04 Aug 2004 15:00:31 +0200 From: Jerome Durand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Spam-Report: Spam detection software, running on the system "mail1.renater.fr", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see postmaster@renater.fr for details. Content preview: > 1) One of the things that both the API and the MADCAP protocol provide > is > allocation of ranges (not "several", but a large number of addresses, > like > a block of 400). This requirement came from applications which want a > larger range to use with things like > a) hashing resource ids into groups (I can't remember the specific > examples here, but IANA often gets requests for blocks of space, and I > believe many of them are for this reason. Dave Meyer can probably > correct me :), > b) assignment to areas inside virtual worlds (from customers in the DIS > industry), [...] Content analysis details: (0.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date X-Spam-Score: 0.6 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Aug 2004 19:33:22 -0400 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > 1) One of the things that both the API and the MADCAP protocol provide > is > allocation of ranges (not "several", but a large number of addresses, > like > a block of 400). This requirement came from applications which want a > larger range to use with things like > a) hashing resource ids into groups (I can't remember the specific > examples here, but IANA often gets requests for blocks of space, and I > believe many of them are for this reason. Dave Meyer can probably > correct me :), > b) assignment to areas inside virtual worlds (from customers in the DIS > industry), I don't beleive we really need this feature. A company that wants plenty of addresses can be allocated manually for example a block. But can be added to the specs. (prefix delegation for IPv6 multicast address could be the answer) > 2) Another thing that both the API and the MADCAP protocol provide is > the ability to enumerate scopes (specifically, human readable names for > them, > and TTLs/HopCounts to use with them). The names for scopes are also > useful > in other contexts besides multicast address allocation. (E.g., see > discussion of > http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options- > 01.txt at http://www.ietf.org/proceedings/03jul/139.htm, has also come > up in MMUSIC, etc.) Hence this capability should be retained. Could be added in information-requests for example. I think this is useful. Jerome > > -Dave > > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 5 00:14:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05787; Thu, 5 Aug 2004 00:14:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsZZH-00032f-Ft; Thu, 05 Aug 2004 00:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsWnv-0005j0-Uy for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 21:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26349 for ; Wed, 4 Aug 2004 21:12:22 -0400 (EDT) Received: from mta3.srv.hcvlny.cv.net ([167.206.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsWrJ-0004Uc-J7 for dhcwg@ietf.org; Wed, 04 Aug 2004 21:15:54 -0400 Received: from optonline.net (ool-43515c70.dyn.optonline.net [67.81.92.112]) by mta3.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I1Y008U88NZRE@mta3.srv.hcvlny.cv.net> for dhcwg@ietf.org; Wed, 04 Aug 2004 21:12:00 -0400 (EDT) Date: Wed, 04 Aug 2004 21:12:24 -0400 From: Tim Niece To: dhcwg@ietf.org Message-id: <41118978.3030402@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 05 Aug 2004 00:09:26 -0400 Subject: [dhcwg] DHCP Options without a Server 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi, I am looking for a DHCP solution that supports Option 78 (for wireless). I was trying to eliminate the need for another server to support DHCP and use the SMC Barricade, but the Barricade does not support the Option 78. If anyone has another option, I would like to hear about it. Tim Niece Rutgers University _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From HPYGKTF@yahoo.com Thu Aug 5 01:11:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08633; Thu, 5 Aug 2004 01:11:48 -0400 (EDT) Received: from bzq-80-45-96.red.bezeqint.net ([82.80.45.96]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bsaaw-0007wW-Nv; Thu, 05 Aug 2004 01:15:22 -0400 Received: from 136.83.240.122 by 132.151.6.1; Thu, 05 Aug 2004 03:08:04 -0300 Message-ID: From: "Kristi Mills" Reply-To: "Kristi Mills" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Looking for cheap high-quality software? Date: Thu, 05 Aug 2004 05:07:04 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--53203467525141410" X-Priority: 1 X-CS-IP: 12.129.112.150 X-Spam-Score: 9.1 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----53203467525141410 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable TOP quality software:

Special Offer #1:
Windows X= P Professional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe - P= hotoshop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macromedia = Dreamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here











?HqdMdYb2YfOAZHHguanine|dhc= ipv6-archive@ietf.org">or un*su*bs*cr*ibe =20 ----53203467525141410-- From dhcwg-bounces@ietf.org Thu Aug 5 14:52:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06336; Thu, 5 Aug 2004 14:52:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsnIs-0007NB-Mf; Thu, 05 Aug 2004 14:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsnC4-0005kV-6V for dhcwg@megatron.ietf.org; Thu, 05 Aug 2004 14:42:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05757 for ; Thu, 5 Aug 2004 14:42:22 -0400 (EDT) Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsnFc-0002f3-1c for dhcwg@ietf.org; Thu, 05 Aug 2004 14:46:04 -0400 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i75IhvRe015129 for ; Thu, 5 Aug 2004 11:43:57 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Thu, 5 Aug 2004 11:41:52 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i75Ifn1P006122; Thu, 5 Aug 2004 11:41:49 -0700 (PDT) Message-Id: <200408051841.i75Ifn1P006122@relay4.apple.com> Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Thu, 5 Aug 2004 11:41:50 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Ralph Droms" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: DHCP discussion list , babatke@ra.rockwell.com, Ted Lemon 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >If it really doesn't matter, why are we having this discussion? Are >you proposing we change DHCP to use an ARP request for announcements? I don't have any personal reason to want it to be one way rather than the other, but I do believe that a good specification shouldn't leave things unspecified. That means we need to decide whether the document will specify ARP request, or ARP reply. It matters little which it is, but we should decide. I originally assumed that it would be logical to use a gratuitous ARP response, but when I started investigating, it seemed that everyone else thought otherwise. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols" (1994) specifies that hosts announce their new address using a broadcast ARP Request. BSD systems announce their new address using a broadcast ARP Request. Macintosh systems announce their new address using a broadcast ARP Request. Windows systems announce their new address using a broadcast ARP Request. So, despite what RFC 2131 may say, it appears that almost all deployed systems in the field actually use ARP Request. Why? I thought about it and compiled a list of all the reasons for picking one rather than the other (already posted to dhcwg), and found that on balance the evidence came out slightly in favour of using ARP Request (which may explain why that's what all the systems do). In conclusion, (i) the arguments weigh slightly in favour of ARP Request, and (ii) most deployed systems in the field use ARP Request, so that's what I decided to write in the ACD draft. To answer your question, we are having this discussion because this is one of those cases where it's equally possible for an intelligent person to argue either side of the argument. Whichever choice the document picks, there is unfortunately an opposing camp willing to fight indefinitely over the decision. If we change the document, then the other camp becomes willing to fight indefinitely to have it changed back. I'm not proposing that we change DHCP. This draft is not DHCP. This draft is Address Conflict Detection as applied generally to any configuration mechanism, including manual static IP addresses. I'm documenting Address Conflict Detection AS IT EXISTS NOW and has existed for a decade or more. If in future DHCP wants to adopt this standardized Address Conflict Detection mechanism, that's a decision for DHC. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Aug 7 09:31:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28855; Sat, 7 Aug 2004 09:31:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtRBA-00018N-3X; Sat, 07 Aug 2004 09:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt6lz-00047g-AE for dhcwg@megatron.ietf.org; Fri, 06 Aug 2004 11:36:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04962 for ; Fri, 6 Aug 2004 11:36:45 -0400 (EDT) Received: from guinness.omniscient.com ([64.134.101.78]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt6pi-0007bK-If for dhcwg@ietf.org; Fri, 06 Aug 2004 11:40:38 -0400 Received: from guinness.omniscient.com (localhost [127.0.0.1]) by guinness.omniscient.com (8.12.11/8.12.11) with ESMTP id i76Faj4d003358; Fri, 6 Aug 2004 11:36:45 -0400 (EDT) Message-Id: <200408061536.i76Faj4d003358@guinness.omniscient.com> To: "Barr Hibbs" Date: Fri, 06 Aug 2004 11:36:45 -0400 From: Todd Kover X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Sat, 07 Aug 2004 09:24:06 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] dhc-server-mib status 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org my apologies if this is covered in the archive; I searched but hadn't seen any conversation on the mib since march 2004. I asked in Dec 2003 about an alternate OID until IANA assigned one (responding to a query about the same earlier that year) to use for the dhcp-server-mib until an official one was assigned and it sounded like the release to rfc was imminent. A new internet draft came out on feb 11, 2004 (-10) and it looks like its six months is about to expire. Where do things stand with the mib becoming an rfc? thanks, -Todd _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From admin@computeradmin.org Sun Aug 8 20:55:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23987; Sun, 8 Aug 2004 20:55:18 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtyVp-0002qM-KD; Sun, 08 Aug 2004 20:59:42 -0400 Received: from commons10k2.mo24.107.93.213.charter-stl.com ([24.107.93.213]) by mx2.foretec.com with smtp (Exim 4.24) id 1BtyRX-0003td-BV; Sun, 08 Aug 2004 20:55:16 -0400 Received: from v2.04oalc.com [253.67.189.4] by commons10k2.mo24.107.93.213.charter-stl.com id <2450375-12888>; Mon, 09 Aug 2004 07:48:33 +0600 Message-ID: From: "Administrator" To: dhcipv6-archive@ietf.org Subject: Staff Bulletin Date: Mon, 09 Aug 04 07:48:33 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".__._8.F..6_F2D.CF" X-Spam-Score: 14.9 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --.__._8.F..6_F2D.CF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Staff Members: You Must Respond By 5 P.M. Tuesday, August 10, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all staff members who respond to this message before 5 P.M., Tuesday, August 10, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Tuesday, August 10, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a school, nonprofit, or healthcare Staff Member. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Tuesday, August 10, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Tuesday, August 10, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --.__._8.F..6_F2D.CF-- From dhcwg-bounces@ietf.org Mon Aug 9 14:32:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24346; Mon, 9 Aug 2004 14:32:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEeA-0001wO-5F; Mon, 09 Aug 2004 14:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEGR-0001XZ-9I for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 13:48:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18407 for ; Mon, 9 Aug 2004 13:48:49 -0400 (EDT) Received: from [64.223.135.10] (helo=Simonelli.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BuEKn-0001ag-Ek for dhcwg@ietf.org; Mon, 09 Aug 2004 13:53:22 -0400 Date: Mon, 09 Aug 2004 13:48:48 -0500 To: "Dhcwg" From: "Erik.nordmark" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ehzsbwohrolugaknylke" X-Spam-Score: 0.9 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [dhcwg] (no subject) 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org ----------ehzsbwohrolugaknylke Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price


----------ehzsbwohrolugaknylke Content-Type: application/octet-stream; name="price2.zip" Content-Disposition: attachment; filename="price2.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------ehzsbwohrolugaknylke Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ----------ehzsbwohrolugaknylke-- From dhcwg-bounces@ietf.org Mon Aug 9 18:04:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24176; Mon, 9 Aug 2004 18:04:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuIDK-0001j7-2K; Mon, 09 Aug 2004 18:01:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuHqW-0002yg-LQ for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 17:38:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21411 for ; Mon, 9 Aug 2004 17:38:17 -0400 (EDT) Received: from adsl-80-168-43.bna.bellsouth.net ([65.80.168.43] helo=bvi-100.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BuHuu-0002hn-KK for dhcwg@ietf.org; Mon, 09 Aug 2004 17:42:54 -0400 Date: Mon, 09 Aug 2004 16:43:23 -0600 To: "Dhcwg" From: "Erik.nordmark" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cmjyjutgxrfxefpfoqnu" X-Spam-Score: 3.6 (+++) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [dhcwg] (no subject) 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org ----------cmjyjutgxrfxefpfoqnu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------cmjyjutgxrfxefpfoqnu Content-Type: application/octet-stream; name="price.zip" Content-Disposition: attachment; filename="price.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------cmjyjutgxrfxefpfoqnu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ----------cmjyjutgxrfxefpfoqnu-- From dhcwg-bounces@ietf.org Mon Aug 9 21:03:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11112; Mon, 9 Aug 2004 21:03:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuL23-00053y-9c; Mon, 09 Aug 2004 21:02:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuKyr-0004Wz-KA for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 20:59:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10684 for ; Mon, 9 Aug 2004 20:59:07 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuL3I-00076J-SJ for dhcwg@ietf.org; Mon, 09 Aug 2004 21:03:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2004 18:01:17 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7A0waYJ009537 for ; Mon, 9 Aug 2004 17:58:36 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS55642; Mon, 9 Aug 2004 20:58:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809203454.02c24468@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 20:58:31 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [dhcwg] Summary notes from dhc WG meeting in San Diego 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Include below is a summary of the WG meeting in San Diego last week. Comments for those who attended are welcome. Several of the agenda items include actions to be confirmed with the WG on the mailing list. I will kick off WG discussion of these actions with subsequent e-mail... - Ralph ===== Meeting Summary dhc WG, IETF 60 2004-08-03, 0900 ---------------- Administrivia Chair announced Samung now has zero-cost licensing IPR claim on draft-ietf-dhc-rapid-commit-opt-05.txt. No objection to moving draft forward. Chair announced no response from PacketFront to request for clarification of IPR claim and to request for zero-cost licensing IPR claim on draft-ietf-dhc-subscriber-id-06.txt. Consensus of meeting is to move draft forward despite current IPR claim. The DHCPv6 Client FQDN Option After some discussion of technical details, meeting consensus was to accept draft-volz-dhc-dhcpv6-fqdn as a WG work item. It will be part of a package of drafts to be submitted to the IESG: draft-volz-dhc-dhcpv6-fqdn draft-ietf-dhc-fqdn-option draft-ietf-dnsext-dhcid-rr-07.txt draft-ietf-dhc-ddns-resolution-07.txt draft-ietf-dhc-3315id-for-v4-03.txt The DHCP Client FQDN Option Meeting consensus was that this draft is ready for WG last call. It will go to last call when other drafts in the package are ready. DHCP Option for Configuring IPv6-over-IPv4 Tunnels Configured Tunnel End-Point Config. using DHCPv4 Discussion focused on . Meeting concensus was to table discussion until dhc and v6ops WG chairs discuss which WG should take on these drafts and how the drafts fit into the v6ops WG discussion of tunnel discovery methods. Vendor-Specific Information Suboption for RAIO Meeting consensus is to accept this draft as a dhc WG work item. Renumbering Requirements for Stateless DHCPv6 Draft to be submitted to IESG independent from any specific solution for publication as an Informational RFC. Meeting consensus was that draft is ready for WG last call. Lifetime Option for DHCPv6 Meeting consensus was to accept this draft as solution chosen by WG to meet requirements in draft-ietf-dhc-stateless-dhcpv6-renumbering. Author to publish revision based on comments from meeting before consideration for WG last call. DHCP Option for Home Agent Discovery in MIPv6 Chair to discuss with mip6 chairs to determine which WG should take on this draft. Is there interest in 3GPP2 to use this option as well? Issues in DHCPv6 authentication Meeting consensus was to take on this draft as a WG work item, to be published as PS, updating RFC 3315. Contents will be merged with RFC 3315 for DS. IPv6 multicast address assignment with DHCPv6 Chair to discuss this draft with mboned chairs to determine where the draft should be reviewed and how to move forward. DHCPv4 Opts. for B-cast and M-cast Control Servers DHCPv6 Opts. for B-cast and M-cast Control Servers These two drafts were discussed together. Chair to discuss these drafts with Int ADs and 3GPP2 liaison to determine how to move the draft forward. IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Meeting consensus was to choose separate servers as solution to dual-stack DHCp service. Discussion of other questions to move to WG mailing list. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 21:34:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14341; Mon, 9 Aug 2004 21:34:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLUy-0001Q2-Nw; Mon, 09 Aug 2004 21:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLI7-0007wB-0M for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 21:19:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12383 for ; Mon, 9 Aug 2004 21:19:01 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuLMX-0007R3-GN for dhcwg@ietf.org; Mon, 09 Aug 2004 21:23:38 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2004 21:18:31 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A1ITdn025077 for ; Mon, 9 Aug 2004 21:18:29 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS56367; Mon, 9 Aug 2004 21:18:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809210048.02c26180@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 21:18:24 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [dhcwg] draft-ietf-dhc-rapid-commit-opt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org draft-ietf-dhc-rapid-commit-opt-05.txt includes a statement that the IETF has been notified about IPR claimed in regard to this specification. The only IPR statement currently published on www.ietf.org is from Samsung, http://www.ietf.org/ietf/IPR/samsung-ipr-draft-ietf-dhc-rapid-commit-opt.txt In this statement, Samsung "agrees to grant a royalty-free license to all parties implementing Samsung's aforesaid draft, subject to reciprocity of the licensed party under essential patents for IETF and IETF's adoption of the draft as the standard." This document is now in front of the IESG. The consensus at the WG meeting in San Diego was to allow the document to progress based on the IPR statement published by Samsung. If there is any objection from the WG to allowing the document to progress, please respond to the dhcwg mailing list by 5PM EDT, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 21:41:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15134; Mon, 9 Aug 2004 21:41:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLVP-0001ed-2d; Mon, 09 Aug 2004 21:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLT8-0000SR-7g for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 21:30:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13956 for ; Mon, 9 Aug 2004 21:30:24 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuLXZ-0007n3-Te for dhcwg@ietf.org; Mon, 09 Aug 2004 21:35:02 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2004 21:29:55 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A1Trdn026623 for ; Mon, 9 Aug 2004 21:29:54 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS56742; Mon, 9 Aug 2004 21:29:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809212324.02b7d100@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 21:26:57 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dhcwg] draft-ietf-dhc-rapid-commit-opt (correction) 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I need to correct my previous message about this document. The document has not passed WG last call and has not yet gone to the IESG. Therefore, the next step for this document is WG last call, and if there is any objection to taking the document to WG last call, please respond to the dhcwg mailing list by 5PM Fir, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 22:03:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17299; Mon, 9 Aug 2004 22:03:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLx1-0007zF-Gm; Mon, 09 Aug 2004 22:01:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLrc-0006g7-P3 for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 21:55:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16461 for ; Mon, 9 Aug 2004 21:55:42 -0400 (EDT) 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.33) id 1BuLw3-0008OC-Hy for dhcwg@ietf.org; Mon, 09 Aug 2004 22:00:20 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Aug 2004 18:42:37 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A1d1F5016387 for ; Mon, 9 Aug 2004 18:39:02 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS57084; Mon, 9 Aug 2004 21:39:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809213015.02c368b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 21:38:57 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [dhcwg] draft-ietf-dhc-subscriber-id 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org draft-ietf-dhc-subscriber-id-06.txt includes a statement that the IETF has been notified about IPR claimed in regard to this specification. The only IPR statement currently published on www.ietf.org regarding draft-ietf-dhc-subscriber-id-06.txt is from PacketFront, http://www.ietf.org/ietf/IPR/PacketFront-IPR.txt. In this statement, PacketFront agrees "to license, on reasonable and non-discriminatory terms, any related PacketFront patents to the extent required to comply with the standard." When this IPR statement was first pointed out to the dhc WG, the WG decided to put the document on hold because of the RAND licensing terms. The IETF Executive Director has tried to contact PacketFront to obtain a clarification of the IPR statement, and I (acting as dhc WG chair) have asked PacketFront to change their IPR statement to grant royalty-free licenses for the use of this technology. PacketFront has not responded to either the IETF Executive Director or to me. This document is now in front of the IESG. The consensus at the WG meeting in San Diego was to allow the document to progress with the RAND licensing IPR statement, due to the lack of response from PacketFront. If there is any objection from the WG to allowing the document to progress, please respond to the dhcwg mailing list by 5PM EDT, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 22:27:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19579; Mon, 9 Aug 2004 22:27:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuMLE-0004aw-M4; Mon, 09 Aug 2004 22:26:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuMEJ-0003U9-T4 for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 22:19:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18802 for ; Mon, 9 Aug 2004 22:19:09 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuMIl-0000YE-0E for dhcwg@ietf.org; Mon, 09 Aug 2004 22:23:48 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2004 22:27:08 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7A2IcKd008296 for ; Mon, 9 Aug 2004 22:18:38 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS58604; Mon, 9 Aug 2004 22:18:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809214047.02b7d100@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 22:18:33 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [dhcwg] draft-ietf-dhc-fqdn-option-07.txt ready for WG last call? 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of the WG meeting was that draft-ietf-dhc-fqdn-option-07.txt is now ready for WG last call. This action needs to be confirmed by full WG consensus. If there is any objection to taking draft-ietf-dhc-fqdn-option-07.txt to WG last call, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. Note that draft-ietf-dhc-fqdn-option-07.txt is one of a set of documents that will go to the IESG as a package. The complete set of documents is: draft-ietf-dhc-fqdn-option draft-volz-dhc-dhcpv6-fqdn draft-ietf-dnsext-dhcid-rr draft-ietf-dhc-ddns-resolution draft-ietf-dhc-3315id-for-v4 All of these documents (except for draft-ietf-dnsext-dhcid-rr, which has already passed WG last call) will go to WG last call as a package when all of the documents are ready. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 23:16:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24150; Mon, 9 Aug 2004 23:16:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuN2a-0005yU-Ty; Mon, 09 Aug 2004 23:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuN1y-0005nS-87 for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 23:10:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23327 for ; Mon, 9 Aug 2004 23:10:27 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuN6P-0001dG-J5 for dhcwg@ietf.org; Mon, 09 Aug 2004 23:15:06 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2004 23:18:27 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7A39pKd017597 for ; Mon, 9 Aug 2004 23:09:56 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS60168; Mon, 9 Aug 2004 23:09:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809230627.02c3fac0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:09:43 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [dhcwg] draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt ready for WG last call? 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of WG members at the WG meeting was to publish draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt as Informational, and that the document is now ready for WG last call. This action needs to be confirmed by full WG consensus. If there is any objection to publishing draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt as Information or to taking the document to WG last call, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 23:17:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24286; Mon, 9 Aug 2004 23:17:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuN2b-0005yZ-FB; Mon, 09 Aug 2004 23:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuN1z-0005nW-Qx for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 23:10:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23334 for ; Mon, 9 Aug 2004 23:10:28 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuN6R-0001dI-2h for dhcwg@ietf.org; Mon, 09 Aug 2004 23:15:08 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2004 20:12:39 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A39v7p016455 for ; Mon, 9 Aug 2004 20:09:57 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS60167; Mon, 9 Aug 2004 23:09:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809230342.02c368b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:05:42 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dhcwg] draft-stapp-dhc-vendor-suboption 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of the WG members at the dhc WG meeting in San Diego was to take on draft-stapp-dhc-vendor-suboption as a WG work item. This action needs to be confirmed by WG consensus. If there is any objection to taking on draft-stapp-dhc-vendor-suboption as WG work item, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 23:30:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25644; Mon, 9 Aug 2004 23:30:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuNGy-00007W-Rh; Mon, 09 Aug 2004 23:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuNCG-0007nZ-VY for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 23:21:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24860 for ; Mon, 9 Aug 2004 23:21:06 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuNGi-0001sv-LU for dhcwg@ietf.org; Mon, 09 Aug 2004 23:25:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2004 23:29:06 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7A3KZKd019670 for ; Mon, 9 Aug 2004 23:20:35 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS60493; Mon, 9 Aug 2004 23:20:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809231731.02c26180@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:20:31 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [dhcwg] draft-ietf-dhc-lifetime as solution of choice? 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of WG members at the WG meeting was to accept this specification as the solution chosen by WG to meet requirements in draft-ietf-dhc-stateless-dhcpv6-renumbering. If there is any objection to accepting draft-ietf-dhc-lifetime as the solution to notifying clients using stateless DHCPv6 that the configuration provided by DHCPv6 may have changed, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 23:46:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26919; Mon, 9 Aug 2004 23:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuNZC-0003MA-Vk; Mon, 09 Aug 2004 23:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuNUS-0002SV-6w for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 23:39:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26339 for ; Mon, 9 Aug 2004 23:39:53 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuNYu-0002F3-05 for dhcwg@ietf.org; Mon, 09 Aug 2004 23:44:33 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7A3Ou13024363 for ; Mon, 9 Aug 2004 20:24:56 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS60588; Mon, 9 Aug 2004 23:24:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809232408.02c3d008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:24:52 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dhcwg] draft-jinmei-dhc-dhcpv6-clarify-auth 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of the WG members at the dhc WG meeting in San Diego was to take on draft-jinmei-dhc-dhcpv6-clarify-auth as a WG work item. This action needs to be confirmed by WG consensus. If there is any objection to taking on draft-jinmei-dhc-dhcpv6-clarify-auth as WG work item, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 07:12:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14115; Tue, 10 Aug 2004 07:12:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUV0-0007s2-Lz; Tue, 10 Aug 2004 07:08:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuURn-0007Kq-6s for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 07:05:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13683 for ; Tue, 10 Aug 2004 07:05:35 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuUWJ-0001gs-KI for dhcwg@ietf.org; Tue, 10 Aug 2004 07:10:20 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7AB52UO029900; Tue, 10 Aug 2004 13:05:05 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7AB51Cl003185; Tue, 10 Aug 2004 13:05:01 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 10 Aug 2004 13:05:00 +0200 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Message-ID: <20040810110500.GB2802@sverresborg.uninett.no> References: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu, Dave Thaler 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, Aug 04, 2004 at 10:25:54AM -0700, Ted Lemon wrote: [...] > The proposal on the table is simpler than MADCAP, not more complicated. > It might be possible to implement even if there is low demand, where > MADCAP, which is a bit fancier, isn't going to get implemented unless > there is high demand. So the way I would frame this issue is, if we > implement the proposal, does that prevent deployment of MADCAP later > when there's enough demand to support widespread implementation of > MADCAP. I think the answer is no. And does implementing this help > people who are trying to solve the real problems in the multicast world > to make forward progress? Apparently some think yes - I have no > opinion since I'm not a multicast guy myself. Finally, is it likely > that people could justify implementing this who can't yet justify > implementing MADCAP? TBF, I don't know. It does look easier to me, > but it still requires significant code changes. It should be easier to implement, and easy to deploy IMO. A DHCP solution should be made as simple as possible, and I don't think it prevents later deployment of MADCAP either. > Following this line of reasoning, I have to say that I'm tempted to ask > the authors to consider whether or not they can make this even simpler. > Do we really need a new IA type, or can we do this with a regular IA > and an option? The reason I ask is that picking which address > allocation pool to use based on an option is well-understood technology > - I think probably every DHCP server vendor already knows how to do > this. And I don't think there are any particularly special > constraints on how address allocation will be done for multicast > addresses - you still just pick one out of a pool. So I think you can > go cheaper on this, and maybe it would feel less like we were trying to > come up with another MADCAP, which doesn't seem like the right thing to > do. Yes, I believe regular IA and option is fine. I would suggest an even simpler approach though. I think it's sufficient for the server to specify which prefix the client should pick the group address from. With prefix based addressing (RFC 3306), including Embedded-RP, you can get a /96-prefix from DHCP server. All clients can get the same /96- prefix. The client would then pick the remaining 32 bits at random. The chances of a collision are minimal, but one could possibly in the future consider some form of DAD or some other way to ensure uniqueness. If not using prefix based addressing, one can still give client a prefix from which it should pick group address, e.g. ff0e::/96. If a client knew that prefix based addressing was used (but not embedded-RP) it could use its own unicast prefix to compute the multicast prefix, but I think the administrator should be able to choose which method should be used. When using embedded-RP, I think it's much cleaner to simply tell application what prefix to use, than to tell it the RP address and require application to compute the prefix. Giving the client a prefix rather than an address allows for several simplifications. First, DHCP server can be stateless, client uses "stateless DHCP". Second, and perhaps more importantly, one doesn't need to hand out addresses to applications. The multicast prefix to be used, could be given to the system together with other DHCP info. It's still a question how applications can learn which prefix to use though. And the DHCP client may not know which scopes an application may want. I would expect a site to only use multicast prefixes from a few scopes though, so one could give the client prefixes for all the scopes. One could also imagine giving the client one prefix, and say which scopes it can be used for. That is, client e.g. receives the prefix "ff3e:40:1234:5678:9abc:def0::/96" and the scope list "5,8,e", meaning that the prefixes ff35:40:1234:5678:9abc:def0::/96, ff38:40:1234:5678:9abc:def0::/96 and ff3e:40:1234:5678:9abc:def0::/96 are to be used for the respective scopes. In this case, the scope used in the prefix itself is ignored. Perhaps there also should be some way to say that a prefix can be used for all scopes. There are some interesting issues wrt handing out addresses to applications. I think either applications must speak DHCP, or there must be some sort of API for applications to communicate with some DHCP middleware... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 07:37:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16002; Tue, 10 Aug 2004 07:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUo0-0002hq-VN; Tue, 10 Aug 2004 07:28:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUjp-0001Yy-KB for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 07:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14896 for ; Tue, 10 Aug 2004 07:24:16 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuUoL-0001zU-DO for dhcwg@ietf.org; Tue, 10 Aug 2004 07:28:58 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7ABNjUO002258; Tue, 10 Aug 2004 13:23:45 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7ABNj0c003214; Tue, 10 Aug 2004 13:23:45 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 10 Aug 2004 13:23:45 +0200 From: Stig Venaas To: Dave Thaler Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Message-ID: <20040810112344.GC2802@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 03, 2004 at 01:36:38PM -0700, Dave Thaler wrote: > Two technical issues on this draft (larger issues sent in separate > email): > > 1) One of the things that both the API and the MADCAP protocol provide > is > allocation of ranges (not "several", but a large number of addresses, > like > a block of 400). This requirement came from applications which want a > larger range to use with things like > a) hashing resource ids into groups (I can't remember the specific > examples here, but IANA often gets requests for blocks of space, and I > believe many of them are for this reason. Dave Meyer can probably > correct me :), > b) assignment to areas inside virtual worlds (from customers in the DIS > industry), > etc. > > These sorts of applications are also the ones most in need of IPv6 > multicast instead of IPv4 multicast, and so the requirement is probably > even more compelling in IPv6. I agree with the needs above. I'm not sure a complex DHCP solution that fully replaces MADCAP is the way to go. I would rather argue for a simplest possible DHCP solution (well, it must be simple but still useful) and say that MADCAP is the alternative if one has additional requirements. > 2) Another thing that both the API and the MADCAP protocol provide is > the ability to enumerate scopes (specifically, human readable names for > them, I'm not sure how important that is for IPv6, if the scoping is to strictly follow the scoping defined by the 4-bit scope field. Or do you want to allow for scopes defined in other ways? I can see some reasons for locally defined names though if the user is to choose which scope to use based on the names. > and TTLs/HopCounts to use with them). The names for scopes are also Do we really need to specify hopcount for IPv6 multicast? For IPv6 we have a large number of well defined scopes, shouldn't scope rather than TTL be used to limit the distribution? > useful > in other contexts besides multicast address allocation. (E.g., see > discussion of > http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options- > 01.txt at http://www.ietf.org/proceedings/03jul/139.htm, has also come > up in MMUSIC, etc.) Hence this capability should be retained. > > -Dave Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 12:42:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10702; Tue, 10 Aug 2004 12:42:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZaW-00027n-RA; Tue, 10 Aug 2004 12:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZD2-0002XZ-9u for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 12:10:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07326 for ; Tue, 10 Aug 2004 12:10:41 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuZHa-0007QL-Ah for dhcwg@ietf.org; Tue, 10 Aug 2004 12:15:27 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 10 Aug 2004 09:10:09 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 09:09:39 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 09:09:43 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 10 Aug 2004 09:08:55 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 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] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Tue, 10 Aug 2004 09:09:29 -0700 Message-ID: Thread-Topic: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR+zJe6vMRaXUXATg6C2Tljd6YSsgAJ6sXA From: "Dave Thaler" To: "Stig Venaas" X-OriginalArrivalTime: 10 Aug 2004 16:08:56.0138 (UTC) FILETIME=[567D2AA0:01C47EF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Stig Venaas writes: > > 2) Another thing that both the API and the MADCAP protocol provide is > > the ability to enumerate scopes (specifically, human readable names for > > them, >=20 > I'm not sure how important that is for IPv6, if the scoping is to > strictly follow the scoping defined by the 4-bit scope field. Or do > you want to allow for scopes defined in other ways? I can see some > reasons for locally defined names though if the user is to choose > which scope to use based on the names. The general point is to get the names when you're multihomed to two different networks. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 13:06:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12709; Tue, 10 Aug 2004 13:06:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZsP-0006s1-O6; Tue, 10 Aug 2004 12:53:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZkz-0004j0-G4 for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 12:45:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10950 for ; Tue, 10 Aug 2004 12:45:46 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuZpX-0008QF-6W for dhcwg@ietf.org; Tue, 10 Aug 2004 12:50:33 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id AEAA01B2308; Tue, 10 Aug 2004 11:43:42 -0500 (CDT) In-Reply-To: <20040810110500.GB2802@sverresborg.uninett.no> References: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> <20040810110500.GB2802@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Tue, 10 Aug 2004 09:45:36 -0700 To: Stig Venaas X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig, maybe you can explain for me how it is less complicated to supply multicast prefixes than it is to do stateful allocation - I don't get it. With multicast prefixes, the client either has to take its chances with the possibility of a collision, which seems quite likely (random number generators are usually deterministic, not random, and getting one that uses any real source of entropy is difficult, not easy), or it has to do some kind of duplicate address detection, which also seems difficult, not easy. In contrast, while stateful address allocation requires slightly more work on the server side (in the sense that the server has to remember which address it allocated), it's much easier on the client side - the client gets a specific address, doesn't need a good RNG, and doesn't need to do multicast DAD. The additional complexity of remembering which IP address we gave to the client is well-understood technology, requiring no innovations and risking no accidental DoS attacks from broken clients. History suggests that DHCP server implementations are more likely to be correct than DHCP client implementations, perhaps because there is less risk of monoculture in the interoperability testing done by a DHCP server vendor than by a DHCP client vendor (a client vendor will typically test against a single server, whereas a server vendor will typically have many different clients to test against). So if it makes sense to do something like this, I would vote for doing it in a stateful manner, not a stateless manner. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 14:32:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19523; Tue, 10 Aug 2004 14:32:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BubH2-0001WS-Hx; Tue, 10 Aug 2004 14:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BubEW-0000v1-Ec for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 14:20:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18803 for ; Tue, 10 Aug 2004 14:20:22 -0400 (EDT) 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.33) id 1BubJ5-00025E-VZ for dhcwg@ietf.org; Tue, 10 Aug 2004 14:25:09 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2004 11:23:34 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7AIJlu7029847; Tue, 10 Aug 2004 11:19:47 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT04546; Tue, 10 Aug 2004 14:19:46 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" Date: Tue, 10 Aug 2004 14:19:46 -0400 Organization: Cisco Message-ID: <000d01c47f06$9dc56ff0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <000701c46ec7$b4728d90$6401a8c0@amer.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: [dhcwg] I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted: At the San Diego DHC WG meeting, you asked whether the complexity of the proposed DHCPv6 client FQDN option is needed? I started out wanting to keep this simple by having ONE client FQDN = option per IA_* option, not one per address (IAADDR option). However, in some preliminary reviews, Ralph commented that this may not be appropriate = for all situations. There are four situations in particular that are important to consider, though the first two are dependent on how clients are likely to request addresses: 1. Suppose a DHCPv6 client is running a multi-homed web server. When = that client requests addresses, for IA_NA IAID=3D1 for example, the DHCPv6 = server may be configured to provide it n global unicast addresses for the = different web sites. Each of these addresses is likely to be associated with a different name. Obviously, the server would also need to be configured = for the DNS name for each of the addresses (and otherwise ignore the clients suggested name, at least on the configured addresses). 2. Suppose a DHCPv6 client requests temporary addresses for IA_TA = IAID=3D1 and also suggests a name for these temporary addresses. The server is = configured to assign 3 temporary addresses and a different name should, ideally, be used for each (since using the same name negates much of the privacy = since the linkage between the names is now in DNS). Note on 1 and 2: In the DHCPv6 specification, we aren't extremely clear = as to what the bounds of an IAID are. For example, should the client really = be requesting multiple IA_NAs and IA_TAs instead of a single of each? If we were to say yes, how does the client know how many to request? Perhaps = this is where a Client API would come in useful - since the web server in = case 1 and the applications that want a privacy address in case 2 should = request the information they need when they need it? And, if there are in = separate IA_*'s, then the unique name for each isn't an issue. 3. Suppose a site is multi-homed and wants to have different names associated with each of the global addresses? This is harder to see as = if I'm at Cisco and there are 3 different ISPs that connect me to the = internet, my system is likely to have ONE "cisco.com" name - not three. But, = perhaps there is a reason to have .isp1.cisco.com, .isp2.cisco.com, .isp3.cisco.com? 4. I saved the most likely for last ... Suppose a client is allocated = both global unicast and unique local unicast addresses. The domain names for these are likely to be different as unique local unicast addresses = shouldn't appear in the global DNS? (Same applies to the to be deprecated = site-local addresses - they too would not be in the same DNS name space.) Perhaps this last case is an argument for considering an IA_UL (unique local, or IA_SL for site-local) option? The current Client FQDN draft would accommodate any of the above, = whereas the simpler model would not. Your comments are always welcome and it would be nice to resolve this = issue soon. I'd like to publish an updated draft (as a DHC WG work item). - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 17:10:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07326; Tue, 10 Aug 2004 17:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Budm0-00053Z-1H; Tue, 10 Aug 2004 17:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BudM1-00024r-Nb for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 16:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02334; Tue, 10 Aug 2004 16:36:14 -0400 (EDT) From: fredrik@packetfront.com Received: from [212.247.6.194] (helo=mailhost.packetfront.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BudQc-0005yr-6F; Tue, 10 Aug 2004 16:41:03 -0400 Received: from www-data by mailhost.packetfront.com with local (Exim 3.35 #1 (Debian)) id 1BudGP-0004C2-00; Tue, 10 Aug 2004 22:30:29 +0200 To: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-subscriber-id Message-ID: <1092169829.411930654f97d@webmail.packetfront.com> Date: Tue, 10 Aug 2004 22:30:29 +0200 (CEST) References: <4.3.2.7.2.20040809213015.02c368b0@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040809213015.02c368b0@flask.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 213.101.86.232 X-Spam-Score: 0.4 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA02334 Cc: dhcwg@ietf.org, ietf-ipr@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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Quoting Ralph Droms : > draft-ietf-dhc-subscriber-id-06.txt includes a statement that the IETF > has been notified about IPR claimed in regard to this specification. > terms. The IETF Executive Director has tried to contact PacketFront > to obtain a clarification of the IPR statement, and I (acting as > dhc WG chair) have asked PacketFront to change their IPR statement > to grant royalty-free licenses for the use of this technology. > PacketFront has not responded to either the IETF Executive Director > or to me. That is correct, we have not responded directly to you or the IETF Execut= ive=20 Director. Our legal office sent the following message on June 30th to the ietf- ipr@ietf.org e-mail address (and received an automatic response that the=20 message had been received [Inquiry #5374]). I am sure you should have bee= n=20 included in the sendlist but for some reason was not. We have not been=20 intentionally unresponsive but I apologize for not including you in the=20 original update. It would be nice though to understand why the content of this message was= not=20 also published on the IETF IPR web-page when it was received.=20 I hope this e-mail will clarify the situation enough for the WG to procee= d as=20 it see fit. As far as PacketFront is concerned we believe that this state= ment=20 is sufficiently clear and that the IPR issues with the subscriber-id draf= t are=20 now resolved to the extent they can be. -----Ursprungligt meddelande----- Fr=E5n: Mats Jonsson [mailto:mats.jonsson@packetfront.com]=20 Skickat: den 30 juni 2004 14:13 Till: 'ietf-ipr@ietf.org' =C4mne: Regarding draft-ietf-dhc-subscriber-id-06. Based on a request from the IETF Dynamic Host Configuration WG, PacketFro= nt Sweden AB hereby would like to make an additional update of its IPR notification from April 17, 2003 and January 29, 2004.=20 The document draft-ietf-dhc-subscriber-id-06.txt describes technology or solutions for which PacketFront has related patents or patent application= s pending. If a document based on this draft becomes an IETF standard PacketFront is prepared to provide a royalty-free license, on otherwise reasonable and non-discriminatory terms based on reciprocity (grant back), any related PacketFront patents to the extent required to comply with the standard. Stockholm June 30, 2004 PacketFront Sweden AB Mats Jonsson _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 18:48:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14442; Tue, 10 Aug 2004 18:48:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BufLb-0008RZ-BU; Tue, 10 Aug 2004 18:43:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BufJQ-0007sR-Ix for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 18:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14143 for ; Tue, 10 Aug 2004 18:41:41 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BufO3-0000km-Gb for dhcwg@ietf.org; Tue, 10 Aug 2004 18:46:31 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 425E2B241F; Tue, 10 Aug 2004 15:41:12 -0700 (PDT) Date: Tue, 10 Aug 2004 15:41:12 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Message-ID: <20040810224111.GA722@isc.org> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 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="===============0583918247==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0583918247== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm surprised this hasn't been discussed...if it has, and I just missed it, please forgive me. Today, there exists a corner case in rfc2131 Client Identifiers that is not clearly defined: In the case where a unique client, probably during its bootstrap [1], should first contact the DHCP server without providing a Client Identifier, and then later contacts the DHCP server again this time using a Client Identifier. The chaddr remains the same between each. In reading rfc2131, it is my estimation that the two are to be treated as unique clients, and each should therefore be offered a unique address. But this is never spelled out. ISC's DHCP server conforms with this interpretation [2]. But, the userbase does not agree in practice. By and large, users expect these two instances of the same client to be granted the same lease. Several (I think "all but ISC's") DHCP server implementations have taken this alternate path, and will give the same address to both clients. The specifics are split into two camps, or so I perceive: The first camp simply ignores any client identifier which adheres to the 'chaddr' convention. This means that both instances of the client are identified by 'chaddr' only. The other camp searches for a lease for a client first by client-id, if the client supplied it, and then by chaddr. If the lease that was found was given to a client with an id, it will still be offered to client without an id based solely on chaddr. If the lease that was found was given to a client without an id, it will still be offered to a client that provides one so long as chaddr matches. Also, at least one client implentation [3] has surfaced to my attention which also depends upon this behaviour. This draft, since it is editing the Client-Identifier definition, could speak to what the server should do in the case where one client identifier is the 'chaddr' convention (it sounds perfectly reasonable to simply ignore all of these, and make them a synonym for chaddr). It could also speak to what the server should do in our brave new future, when the PXE clients that exist still today and don't send client-ids are mixed with new host operating systems that will send the new id this draft defines. The upgrade path for PXE is not as easy as the host operating systems, and no doubt will lag several years behind adoption by operating systems. It does neither, and obviously I think it should at least do one of those. I'm willing to recommend verbage after discussion. [1] Intel PXE clients do not send a Client Identifier, but many host operating systems which they pass execution to are infected with the 'send chaddr as Client Identifier' disease. The result is that such boxes burn two IP addresses. [2] Make no mistake, I did not write this code, I merely agree with its interpretation of the RFC's. [3] A Microsoft Windows product (XPe I think it is called) designed for Embedded Systems not only expects to be booted within a PXE environment, and provides chaddr as its client-identifier...but gets its initial address from the PXE environment and will not act upon any OFFER that does not provide the same address (it seems it can read state from PXE, but it cannot over-ride what it has learned from same, as if the network device is no longer under its control). So if it were to speak to a DHCP server that intended a new address for it, it would never escape INIT state (it sits there sending a DISCOVER every few seconds with a requested-address option set). --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGU8HcXeLeWu2vmoRAtLNAJ9D0hIEd42mEQ77M/MH1xiRFrDeoACglgKH g7QSBstSS/tc97CHjtxGBuM= =WHZF -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- --===============0583918247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0583918247==-- From MFDNIC@yahoo.com Tue Aug 10 21:54:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23953; Tue, 10 Aug 2004 21:54:57 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuiP6-0003lx-75; Tue, 10 Aug 2004 21:59:48 -0400 Received: from cm-ranc0-207-100.cm.vtr.net ([200.104.207.100]) by mx2.foretec.com with smtp (Exim 4.24) id 1BuiKO-0005pN-4q; Tue, 10 Aug 2004 21:54:56 -0400 Received: from 66.53.240.166 by web106.mail.yahoo.com; Tue, 10 Aug 2004 21:47:47 -0500 Message-ID: From: "Shelley Guy" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Need software? Click here. Date: Wed, 11 Aug 2004 04:53:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--808456926352742" X-CS-IP: 92.8.0.214 X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----808456926352742 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable TOP quality software:

Special Offer #1:
Windows = XP Professional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe - Phot= oshop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macromedia Dreamwa= ver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

En= ter Here











?HqdMdYb2YfOAZHHi= ntact|dhcipv6-archive@ietf.org">or un*su*bs*cr*ibe =20 ----808456926352742-- From dhcwg-bounces@ietf.org Wed Aug 11 06:40:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19318; Wed, 11 Aug 2004 06:40:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqV3-000751-FA; Wed, 11 Aug 2004 06:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqTj-0006tp-FQ for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 06:37:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19161 for ; Wed, 11 Aug 2004 06:37:04 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuqYS-0003HZ-MR for dhcwg@ietf.org; Wed, 11 Aug 2004 06:42:01 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7BAaN2M015866; Wed, 11 Aug 2004 12:36:23 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7BAaMSL005402; Wed, 11 Aug 2004 12:36:22 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 11 Aug 2004 12:36:22 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040811103622.GF5086@sverresborg.uninett.no> References: <200408030929.31655.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408030929.31655.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 03, 2004 at 09:33:29AM -0400, Joe Quanaim wrote: > > JINMEI Tatuya / ???????????? wrote: > [...] > > 2. the usage of the lifetime option for other exchanges than > > Info-req/Reply exchanges. > > > > I'm even not 100% sure if the lifetime can be used for the other > > types of exchanges. Probably it can according to the draft, but > > then I'll have several questions on how to use it. > > > > For example, the draft says: > > > > Before making the request it MUST wait for a random amount of time > > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. > > > > Is this also applies to the other cases even if INF_MAX_DELAY is a > > dedicated parameter for Info-req? If so, is it really valid? > > Isn't this duplicating rfc 3315? Removing it would prevent any subsequent > updates to rfc 3315 from conflicing with this statement. So what you're saying is that should say 1 sec, rather than INF_MAX_DELAY? Or are you saying that shouldn't specify random delay at all? At first I didn't see the need for random delay since there is one prior to the first information request according to rfc 3315, but as someone said it might be required. If for instance the client checks for expired lifetime every second or less often. > > Also, how does the client exactly react to the expiration event for > > the other cases? For example, consider the following scenario: > > > > - the client performs Solicit->Advertise->Request->Reply exchanges, > > and gets an IPv6 address allocated, a DNS server address X, and an > > associated lifetime T. > > - before the timeout "T1" for the allocated address passes, lifetime > > T expires. In this case, should the client restart the entire > > session from Solicit? Or should the client send a renew message? > > If so, the renew message also tries to update the allocated > > address even if it's too early? Or should the client even start > > Information-request/Reply exchanges just to update the DNS address > > information? > > Using this option in a stateful transaction makes things more complicated. > The lifetime option can expire between t1, t2, or the valid lifetime of an > address. As Jinmei Tatuya notes, what should the client be expected to do? > Restart the message exchange; just do an information-request; etc. > > Any negotiated value for t1, t2, or valid lifetime of an address could take > precedence over the lifetime option. This essentially makes the option > stateless only, but it simplifies the resulting changes to a client > implementation. I'm happy with this. If anyone got other opinions, please speak up. I'll mail text suggestion soon, > Joe Quanaim. Thanks, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 10:04:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05829; Wed, 11 Aug 2004 10:04:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Butbk-0005mX-7A; Wed, 11 Aug 2004 09:57:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Butam-0005Wi-SS for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 09:56:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05155 for ; Wed, 11 Aug 2004 09:56:34 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ButfU-00085P-QU for dhcwg@ietf.org; Wed, 11 Aug 2004 10:01:32 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i7BDtpRF029613; Wed, 11 Aug 2004 08:55:52 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7BDto413909; Wed, 11 Aug 2004 09:55:50 -0400 (EDT) From: Joe Quanaim To: Stig Venaas Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Wed, 11 Aug 2004 09:55:04 -0400 User-Agent: KMail/1.5.4 References: <200408030929.31655.jdq@lucent.com> <20040811103622.GF5086@sverresborg.uninett.no> In-Reply-To: <20040811103622.GF5086@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408110955.05204.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > On Tue, Aug 03, 2004 at 09:33:29AM -0400, Joe Quanaim wrote: > > JINMEI Tatuya / ???????????? wrote: > > [...] > > > > > 2. the usage of the lifetime option for other exchanges than > > > Info-req/Reply exchanges. > > > > > > I'm even not 100% sure if the lifetime can be used for the other > > > types of exchanges. Probably it can according to the draft, but > > > then I'll have several questions on how to use it. > > > > > > For example, the draft says: > > > > > > Before making the request it MUST wait for a random amount of time > > > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC > > > 3315]. > > > > > > Is this also applies to the other cases even if INF_MAX_DELAY is a > > > dedicated parameter for Info-req? If so, is it really valid? > > > > Isn't this duplicating rfc 3315? Removing it would prevent any > > subsequent updates to rfc 3315 from conflicing with this statement. > > So what you're saying is that should say 1 sec, rather than > INF_MAX_DELAY? Or are you saying that shouldn't specify random delay > at all? > > At first I didn't see the need for random delay since there is one > prior to the first information request according to rfc 3315, but as > someone said it might be required. If for instance the client checks > for expired lifetime every second or less often. Ok. I felt like the entire statement was repeating rfc 3315 and could be removed. Looking again, I think you are trying to differentiate between the first info request (which 3315 dictates) and enforce the INF_MAX_DELAY for subsequent info requests after a lifetime expires. I am okay with that. I would have considered this to be a new exchange and therefore under the 3315 guidelines, but having it spelled out does not hurt. Also, if a client is checking for an expired lifetime every second, that's a problem. Perhaps we should add a statement saying that a client should not recheck lifetimes without waiting a period of at least half the received lifetime. It would need to be should instead of must to allow client reboots and such, but it would at least make bombarding a server with requests inappropriate behavior. > > > Also, how does the client exactly react to the expiration event for > > > the other cases? For example, consider the following scenario: > > > > > > - the client performs Solicit->Advertise->Request->Reply exchanges, > > > and gets an IPv6 address allocated, a DNS server address X, and an > > > associated lifetime T. > > > - before the timeout "T1" for the allocated address passes, lifetime > > > T expires. In this case, should the client restart the entire > > > session from Solicit? Or should the client send a renew message? > > > If so, the renew message also tries to update the allocated > > > address even if it's too early? Or should the client even start > > > Information-request/Reply exchanges just to update the DNS address > > > information? > > > > Using this option in a stateful transaction makes things more > > complicated. The lifetime option can expire between t1, t2, or the valid > > lifetime of an address. As Jinmei Tatuya notes, what should the client > > be expected to do? Restart the message exchange; just do an > > information-request; etc. > > > > Any negotiated value for t1, t2, or valid lifetime of an address could > > take precedence over the lifetime option. This essentially makes the > > option stateless only, but it simplifies the resulting changes to a > > client implementation. > > I'm happy with this. If anyone got other opinions, please speak up. > I'll mail text suggestion soon, I feel like this statement is sufficient for the current ia's: na, ta, and pd. > > Joe Quanaim. > > Thanks, > > Stig Thanks, Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 10:22:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07947; Wed, 11 Aug 2004 10:22:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ButxB-0006qr-HD; Wed, 11 Aug 2004 10:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Butq1-0003zE-S7 for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 10:12:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06859 for ; Wed, 11 Aug 2004 10:12:19 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Butum-0008NF-6V for dhcwg@ietf.org; Wed, 11 Aug 2004 10:17:17 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:99b8:98fa:2262:6c66]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7F87B1525D; Wed, 11 Aug 2004 23:12:17 +0900 (JST) Date: Wed, 11 Aug 2004 23:12:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <000201c4797e$2a5f37e0$46828182@amer.cisco.com> References: <200408030929.31655.jdq@lucent.com> <000201c4797e$2a5f37e0$46828182@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: venaas@uninett.no, tjc@ecs.soton.ac.uk, jdq@lucent.com, 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 3 Aug 2004 13:20:22 -0400, >>>>> "Bernie Volz" said: > I too would recommend that this option only be used with stateless > (Information-Request/Reply). It does not apply to stateful - in stateful, > even if there are no T1/T2 times (i.e., no IA_NA option), the client will > need to do something when it no longer has addresses so it will get new > information from the server. I tend to agree. In addition to the above points, I'd like to point out that in the stateful exchanges the server can initiate update by Reconfigure - at least in theory. 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 Aug 11 15:39:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02513; Wed, 11 Aug 2004 15:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuylM-0007fL-TN; Wed, 11 Aug 2004 15:27:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuydM-0002Rt-AA for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 15:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00284 for ; Wed, 11 Aug 2004 15:19:34 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buyi6-0005vI-Kl for dhcwg@ietf.org; Wed, 11 Aug 2004 15:24:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2004 12:21:58 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7BJIqK7016565 for ; Wed, 11 Aug 2004 12:18:58 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (dhcp-10-86-160-38.cisco.com [10.86.160.38]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT87657; Wed, 11 Aug 2004 15:18:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20040811150633.02004b08@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Aug 2004 15:15:05 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a second WG last call on "DHCP Option for Proxy Server Configuration" . There was insufficient (that is, none) response to the first WG last call. This document can not be submitted to the IESG without positive response during the WG last call. This last call will conclude at 1700 EDT, 2004-08-27. 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. "DHCP Option for Proxy Server Configuration" defines a Dynamic Host Configuration Protocol (DHCP) option that can be used to configure the TCP/IP host's Proxy Server configuration for standard protocols like HTTP, FTP, NNTP, SOCKS, Gopher, SLL and etc. Proxy servers provide controlled and efficient access to the Internet through the use of access control mechanisms for different types of user requests and caching frequently accessed information (Web pages and other files that might have been downloaded using FTP and other protocols). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.txt - Ralph Droms _______________________________________________ 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 Aug 11 15:42:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02842; Wed, 11 Aug 2004 15:42:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuylN-0007gZ-CY; Wed, 11 Aug 2004 15:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuydM-0002S2-Eg for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 15:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00288 for ; Wed, 11 Aug 2004 15:19:34 -0400 (EDT) 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.33) id 1Buyi6-0005vH-Kf for dhcwg@ietf.org; Wed, 11 Aug 2004 15:24:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2004 12:21:22 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7BJIrK7016573 for ; Wed, 11 Aug 2004 12:18:58 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (dhcp-10-86-160-38.cisco.com [10.86.160.38]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT87658; Wed, 11 Aug 2004 15:18:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20040811151653.020898a8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Aug 2004 15:17:48 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-v4-threat-analysis-02 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a second WG last call on "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" . There was insufficient (that is, none) response to the first WG last call. This document can not be submitted to the IESG without positive response during the WG last call. This last call will conclude at 1700 EDT, 2004-08-27. 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. "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol. DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration of host systems in a TCP/IPv4 network. RFC 2131 did not provide for authentication of clients and servers, nor did it provide for data confidentiality. This is reflected in the original "Security Considerations" section of RFC 2131, which identifies a few threats and leaves development of any defenses against those threats to future work. Beginning in about 1995 DHCP security began to attract attention from the Internet community, eventually resulting in the publication of RFC 3118 in 2001. Although RFC 3118 was a mandatory prerequisite for the DHCPv4 Reconfigure Extension, RFC 3203, it has had no known usage by any commercial or private implementation since its adoption. The DHC Working Group has adopted a work item to review and modify or replace RFC 3118 to afford a workable, easily deployed security mechanism for DHCPv4. This memo provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol for use both as RFC 2131 advances from Draft Standard to Full Standard and to support our chartered work improving the acceptance and deployment of RFC 3118. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-02.txt - Ralph Droms _______________________________________________ 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 Aug 11 15:55:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04519; Wed, 11 Aug 2004 15:55:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buylj-0007wn-6L; Wed, 11 Aug 2004 15:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buyf8-00041c-4E; Wed, 11 Aug 2004 15:21:26 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00638; Wed, 11 Aug 2004 15:21:23 -0400 (EDT) Message-Id: <200408111921.PAA00638@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 11 Aug 2004 15:21:23 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-05.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Authentication Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, T. Lemon Filename : draft-ietf-dhc-auth-suboption-05.txt Pages : 15 Date : 2004-8-11 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-auth-suboption-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-auth-suboption-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-11152548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-suboption-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-suboption-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-11152548.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Aug 11 18:21:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26241; Wed, 11 Aug 2004 18:21:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv18a-0007Bf-3N; Wed, 11 Aug 2004 18:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0x2-0001K2-G1 for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 17:48:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21630 for ; Wed, 11 Aug 2004 17:48:01 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv11o-0004JI-TE for dhcwg@ietf.org; Wed, 11 Aug 2004 17:53:04 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2004 14:50:26 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7BLlNVD010155; Wed, 11 Aug 2004 14:47:23 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU01354; Wed, 11 Aug 2004 17:47:21 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 - NO GO! Date: Wed, 11 Aug 2004 17:47:21 -0400 Organization: Cisco Message-ID: <002001c47fec$c84326f0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4.3.2.7.2.20040811150633.02004b08@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: neumann@wu-wien.ac.at, ksenthil@india.hp.com, srihary@cisco.com, exand@wu-wien.ac.at 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I do *NOT* agree with the last call on this document! The current document is http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt= and I assume that is really the one being last called and the one I'll comment on (as there are significant differences between 00 and 01). First, I'd like to understand how they'll encode values such as 1080 = into a single byte: The Proxy Server Configuration entry consists of a sequence of=20 Protocol Type (p), Encoding (e), IP address and port.=20 =20 +--+--+--+--+--+--+--+--+ |p |e |IP address |port | +--+--+--+--+--+--+--+--+ The Protocol(p) and encodig (e) are on octet each; each IP address is ---------------------------------------^^ (I assume this is ONE octet = each?) four octets, and each port number is a two-octet integer encoded in network byte order. And then: The protocol type(p) specifies the type of Protocol and MUST be=20 one of the following assigned numbers. +-------------------------------+ | protocol | Number | +-------------------------------+ | HTTP | 80 | +-------------------------------+ | FTP | 21 | +-------------------------------+ | NNTP | 119 | +-------------------------------+ | Gopher | 70 | +-------------------------------+ | SSL | TBD | +-------------------------------+ | SOCKS | 1080 | =20 1080 requires two bytes to encode. Later, the document goes on about: The format of the Proxy Server Configuration using Metadata type is: p Len RDF Metadata for the Proxy =20 +-------+------+----------------------------------+ | RDF | N | RDF | +-------+------+----------------------------------+ What is this and where does this go? Is this a new option? Is this = encoded in the existing option in some manner which I can't understand? And, the option size would seem to exceed the 255 byte limit: "... = giving a total of 418 characters including the overhead", yet nothing is ever mentioned about RFC 3396 (encoding long options). So, I think this draft needs much further revision before I feel it = would be acceptable. Best regards, - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Wednesday, August 11, 2004 3:15 PM > To: dhcwg@ietf.org > Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 >=20 >=20 > This message announces a second WG last call on "DHCP Option=20 > for Proxy Server Configuration"=20 > . There was insufficient=20 > (that is, none) response to the first WG last call. This=20 > document can not be submitted to the IESG without positive=20 > response during the WG last call. This last call will=20 > conclude at 1700 EDT, 2004-08-27. >=20 > Please respond to this WG last call. If you support=20 > acceptance of the document without change, respond with a=20 > simple acknowledgment, so that support for the document can=20 > be assessed. >=20 > "DHCP Option for Proxy Server Configuration" defines a=20 > Dynamic Host Configuration Protocol (DHCP) option that can be=20 > used to configure the TCP/IP host's Proxy Server=20 > configuration for standard protocols like HTTP, FTP, NNTP,=20 > SOCKS, Gopher, SLL and etc. Proxy servers provide controlled=20 > and efficient access to the Internet through the use of=20 > access control mechanisms for different types of user=20 > requests and caching frequently accessed information (Web=20 > pages and other files that might have been downloaded using=20 > FTP and other protocols). This draft is available as=20 http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.txt= - Ralph Droms _______________________________________________ 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 Wed Aug 11 18:24:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26414; Wed, 11 Aug 2004 18:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv18i-0007Gw-QL; Wed, 11 Aug 2004 18:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0yM-0001rc-4j for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 17:49:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21787 for ; Wed, 11 Aug 2004 17:49:23 -0400 (EDT) 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.33) id 1Bv139-0004MN-Ht for dhcwg@ietf.org; Wed, 11 Aug 2004 17:54:26 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2004 14:52:48 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7BLlYCL009630; Wed, 11 Aug 2004 14:47:40 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU01460; Wed, 11 Aug 2004 17:48:40 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-v4-threat-analysis-02 Date: Wed, 11 Aug 2004 17:48:40 -0400 Organization: Cisco Message-ID: <002101c47fec$f6df1140$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4.3.2.7.2.20040811151653.020898a8@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I, as one of the authors, fully support this document moving forward. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Wednesday, August 11, 2004 3:18 PM > To: dhcwg@ietf.org > Subject: [dhcwg] dhc WG last call on=20 > draft-ietf-dhc-v4-threat-analysis-02 >=20 >=20 > This message announces a second WG last call on "Dynamic Host=20 > Configuration Protocol for IPv4 (DHCPv4) Threat Analysis"=20 > . There was=20 > insufficient (that is, > none) response to the first WG last call. This document can=20 > not be submitted to the IESG without positive response during=20 > the WG last call. This last call will conclude at 1700 EDT,=20 > 2004-08-27. >=20 > Please respond to this WG last call. If you support=20 > acceptance of the document without change, respond with a=20 > simple acknowledgment, so that support for the document can=20 > be assessed. >=20 > "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat=20 > Analysis" provides a comprehensive threat analysis of the=20 > Dynamic Host Configuration Protocol. DHCPv4 (RFC 2131) is a=20 > stable, widely used protocol for configuration of host=20 > systems in a TCP/IPv4 network. RFC 2131 did not provide for=20 > authentication of clients and servers, nor did it provide for=20 > data confidentiality. This is reflected in the original=20 > "Security Considerations" section of RFC 2131, which=20 > identifies a few threats and leaves development of any=20 > defenses against those threats to future work. Beginning in=20 > about 1995 DHCP security began to attract attention from the=20 > Internet community, eventually resulting in the publication=20 > of RFC 3118 in 2001. Although RFC 3118 was a mandatory=20 > prerequisite for the DHCPv4 Reconfigure Extension, RFC 3203,=20 > it has had no known usage by any commercial or private=20 > implementation since its adoption. The DHC Working Group has=20 > adopted a work item to review and modify or replace RFC 3118=20 > to afford a workable, easily deployed security mechanism for=20 > DHCPv4. This memo provides a comprehensive threat analysis of=20 > the Dynamic Host Configuration Protocol for use both as RFC=20 > 2131 advances from Draft Standard to Full Standard and to=20 > support our chartered work improving the acceptance and=20 > deployment of RFC 3118. This draft is available as=20 http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-02.= txt - Ralph Droms _______________________________________________ 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 Wed Aug 11 18:25:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26654; Wed, 11 Aug 2004 18:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1Dy-0003lZ-Gq; Wed, 11 Aug 2004 18:05:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv17G-0006Tu-EB for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 17:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23264 for ; Wed, 11 Aug 2004 17:58:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1C5-0004rx-R9 for dhcwg@ietf.org; Wed, 11 Aug 2004 18:03:38 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2004 17:58:07 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7BLw49d002188; Wed, 11 Aug 2004 17:58:04 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU02147; Wed, 11 Aug 2004 17:58:04 -0400 (EDT) From: "Bernie Volz" To: "'David W. Hankins'" , Subject: RE: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Wed, 11 Aug 2004 17:58:04 -0400 Organization: Cisco Message-ID: <002201c47fee$47009120$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040810224111.GA722@isc.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: rbhibbs@pacbell.net 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I believe this really is more appropriate in draft-ietf-dhc-implementation-*.txt, though the (01) draft appears to = have expired. In particular, in section 2.4/2.5: 2.4. The Client Hardware Address, = "chaddr"......................7=20 2.5. The DHCP Client = Identifier.................................7=20 2.5.1. = Uniqueness............................................7=20 2.5.2. Prohibition in DHCPOFFER and = DHCPACK..................8=20 This really has little to do with defining a DHCPv6 DUID for DHCPv4 = clients. Best regards, Bernie Volz > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of David W. Hankins > Sent: Tuesday, August 10, 2004 6:41 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 >=20 >=20 > I'm surprised this hasn't been discussed...if it has, and I=20 > just missed it, please forgive me. >=20 >=20 > Today, there exists a corner case in rfc2131 Client=20 > Identifiers that is not clearly defined: >=20 > In the case where a unique client, probably during its=20 > bootstrap [1], should first contact the DHCP server without=20 > providing a Client Identifier, and then later contacts the=20 > DHCP server again this time using a Client Identifier. The=20 > chaddr remains the same between each. >=20 > In reading rfc2131, it is my estimation that the two are to=20 > be treated as unique clients, and each should therefore be=20 > offered a unique address. But this is never spelled out. >=20 > ISC's DHCP server conforms with this interpretation [2]. =20 > But, the userbase does not agree in practice. By and large,=20 > users expect these two instances of the same client to be=20 > granted the same lease. >=20 > Several (I think "all but ISC's") DHCP server implementations=20 > have taken this alternate path, and will give the same=20 > address to both clients. The specifics are split into two=20 > camps, or so I perceive: >=20 > The first camp simply ignores any client identifier which=20 > adheres to the 'chaddr' convention. This means that both=20 > instances of the client are identified by 'chaddr' only. >=20 > The other camp searches for a lease for a client first by=20 > client-id, if the client supplied it, and then by chaddr. If=20 > the lease that was found was given to a client with an id, it=20 > will still be offered to client without an id based solely on=20 > chaddr. If the lease that was found was given to a client=20 > without an id, it will still be offered to a client that=20 > provides one so long as chaddr matches. >=20 > Also, at least one client implentation [3] has surfaced to my=20 > attention which also depends upon this behaviour. >=20 >=20 > This draft, since it is editing the Client-Identifier=20 > definition, could speak to what the server should do in the=20 > case where one client identifier is the 'chaddr' convention=20 > (it sounds perfectly reasonable to simply ignore all of=20 > these, and make them a synonym for chaddr). >=20 > It could also speak to what the server should do in our brave=20 > new future, when the PXE clients that exist still today and=20 > don't send client-ids are mixed with new host operating=20 > systems that will send the new id this draft defines. The=20 > upgrade path for PXE is not as easy as the host operating=20 > systems, and no doubt will lag several years behind adoption=20 > by operating systems. >=20 > It does neither, and obviously I think it should at least do=20 > one of those. >=20 >=20 > I'm willing to recommend verbage after discussion. >=20 >=20 > [1] Intel PXE clients do not send a Client Identifier, but many host > operating systems which they pass execution to are infected with > the 'send chaddr as Client Identifier' disease. The result is > that such boxes burn two IP addresses. >=20 > [2] Make no mistake, I did not write this code, I merely agree with > its interpretation of the RFC's. >=20 > [3] A Microsoft Windows product (XPe I think it is called) designed > for Embedded Systems not only expects to be booted within a PXE > environment, and provides chaddr as its client-identifier...but > gets its initial address from the PXE environment and will not > act upon any OFFER that does not provide the same address (it > seems it can read state from PXE, but it cannot over-ride what > it has learned from same, as if the network device is no longer > under its control). So if it were to speak to a DHCP server that > intended a new address for it, it would never escape INIT state > (it sits there sending a DISCOVER every few seconds with a > requested-address option set). >=20 > --=20 > David W. Hankins "If you don't do it right the=20 > first time, > Operations Engineer you'll just have to do=20 > it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 18:54:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28536; Wed, 11 Aug 2004 18:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1q9-0000fy-Hv; Wed, 11 Aug 2004 18:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1hB-0006cR-EL for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 18:35:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27277 for ; Wed, 11 Aug 2004 18:35:42 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1lx-0005i9-UP for dhcwg@ietf.org; Wed, 11 Aug 2004 18:40:45 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 4326E1B2EF5; Wed, 11 Aug 2004 17:33:29 -0500 (CDT) In-Reply-To: <002201c47fee$47009120$d0412ca1@amer.cisco.com> References: <002201c47fee$47009120$d0412ca1@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Wed, 11 Aug 2004 15:35:28 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, rbhibbs@pacbell.net 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 11, 2004, at 2:58 PM, Bernie Volz wrote: > I believe this really is more appropriate in > draft-ietf-dhc-implementation-*.txt, though the (01) draft appears to > have > expired. In particular, in section 2.4/2.5: Yeah. I don't have a lot of help to offer with this. If a PXE client can't be configured with a specific client identifier, there's not a whole lot to be done about it. It's definitely a mistake to just use the mac address as an identifier and ignore the client identifier. Probably a post-boot client in a PXE environment should just use the identifier the PXE client used. Such a client can't do ngtrans anyway, since its boot prom is IPv4-only. Or if it can do ngtrans, the way to do it is to just get a restricted IPv4 address, load the O.S. , and then use the O.S. DHCP client to get a proper IP address, and throw away the address that PXE got. You can easily hack most DHCP servers to allocate PXE addresses out of a non-routable subnet (e.g., 10.x.x.x). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 19:08:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29279; Wed, 11 Aug 2004 19:08:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1yX-0002Th-Fv; Wed, 11 Aug 2004 18:53:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1pX-0000br-9A for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 18:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28018 for ; Wed, 11 Aug 2004 18:44:20 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1uM-0005vN-BI for dhcwg@ietf.org; Wed, 11 Aug 2004 18:49:23 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 67562B241F; Wed, 11 Aug 2004 15:43:50 -0700 (PDT) Date: Wed, 11 Aug 2004 15:43:50 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040811224350.GJ746@isc.org> References: <20040810224111.GA722@isc.org> <002201c47fee$47009120$d0412ca1@amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <002201c47fee$47009120$d0412ca1@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: rbhibbs@pacbell.net 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="===============1289318989==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1289318989== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DesjdUuHQDwS2t4N" Content-Disposition: inline --DesjdUuHQDwS2t4N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 05:58:04PM -0400, Bernie Volz wrote: > I believe this really is more appropriate in > draft-ietf-dhc-implementation-*.txt, though the (01) draft appears to have I don't have a copy of that draft, so I can only guess that it attempts to clarify the server's behaviour in regards to the original Client Identifier? How is that the right place for defining the expected behaviour of the server when it encounters the v6 DUID from v4 clients that previously were only identified by chaddr? Sure, if we decide not to go ahead with the v6 DUID (not likely), I think reviving that draft would be noble, but...I like the v6 DUID. I think we should just define the sane and rational behaviour we expect of the server when it encounters the mixed identities, since we already appear to have a consensus on what that should be. Sending the draft to RFC knowing full well we're going to have to submit similar clarifying work on its contents later seems like a lot more work to me. We could just avoid all that. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --DesjdUuHQDwS2t4N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGqElcXeLeWu2vmoRAgPIAJ4pFx7a59roQHePEJ8/7axPz4dY/wCfYC9t Cnc4dBSm3ILfovqOxWyR2Ew= =u0bH -----END PGP SIGNATURE----- --DesjdUuHQDwS2t4N-- --===============1289318989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1289318989==-- From dhcwg-bounces@ietf.org Wed Aug 11 21:41:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07072; Wed, 11 Aug 2004 21:41:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv4Yr-0003zn-F4; Wed, 11 Aug 2004 21:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv4U0-0003QZ-5s for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 21:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06867 for ; Wed, 11 Aug 2004 21:34:18 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv4Yq-0008Qz-Ej for dhcwg@ietf.org; Wed, 11 Aug 2004 21:39:21 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id C6CC41B2F04; Wed, 11 Aug 2004 20:32:05 -0500 (CDT) In-Reply-To: <20040811224350.GJ746@isc.org> References: <20040810224111.GA722@isc.org> <002201c47fee$47009120$d0412ca1@amer.cisco.com> <20040811224350.GJ746@isc.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Wed, 11 Aug 2004 18:34:13 -0700 To: "David W. Hankins" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, rbhibbs@pacbell.net 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 11, 2004, at 3:43 PM, David W. Hankins wrote: > I think we should just define the sane and rational behaviour we > expect of the server when it encounters the mixed identities, since > we already appear to have a consensus on what that should be. David, in the case you are describing, the DHCP client has no stable storage. So there's no benefit to implementing the new client identifier type on that client. The server's behavior towards clients that are out of compliance with the draft but do follow RFC2131/2132 is clearly stated in the draft. A host operating system that has been booted by a PXE boot loader that does not comply with this draft, along with the PXE boot loader itself, together represent a system which can never be in compliance with this draft. The host operating system should use the same identifier that the PXE client uses, whatever that is, and not make up its own. If the host operating does in fact make up its own identifier, then we are talking about two different DHCP clients, one of which follows the spec, and one of which does not. The two clients will get two different IP addresses. There is no harm in this, unless you are concerned about excessive IP address consumption. If you are concerned about that, there are stopgap solutions to get you over the hump until the last of those PXE cards dies a well-deserved death. While I sympathize with the issue you are raising, before you go any further I would suggest that you read the problem statement, and then sit down and see if you can write text that resolves the issue you are raising in any better way than the current draft does, while at the same time not failing to meet the goals of the current draft. When you haven't tried yourself to write the text that addresses a problem you're describing in the context of the draft to which you wish to add the text, it's easy to imagine that there is some solution that could be grafted onto any particular document. It is by such mistakes that documents get delayed, sometimes forever, in their journey through the standards process. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 22:49:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10225; Wed, 11 Aug 2004 22:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv5X1-0005kg-72; Wed, 11 Aug 2004 22:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv5TX-00058y-9l for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 22:37:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09834 for ; Wed, 11 Aug 2004 22:37:53 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv5YO-0000yk-G7 for dhcwg@ietf.org; Wed, 11 Aug 2004 22:42:57 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2004 22:46:13 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7C2bKCf015514; Wed, 11 Aug 2004 22:37:20 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-1-171.cisco.com [10.86.240.171]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU15907; Wed, 11 Aug 2004 22:37:19 -0400 (EDT) From: "Bernie Volz" To: "'David W. Hankins'" , Subject: RE: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Wed, 11 Aug 2004 22:37:18 -0400 Organization: Cisco Message-ID: <001701c48015$49540c50$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040811224350.GJ746@isc.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: rbhibbs@pacbell.net 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Perhaps I'm not understanding the issue fully, but isn't this a problem if a client first sends NO client identifier (to boot) and then (once the O/S is running) sends a client identifier? Agreed that today many client identifiers are generated from the hardware address and 3315id makes this more problematic (since we don't want servers to look into the DUID) but this, IMHO, is a general problem whenever this switch from no-client identifier to client identifier happens. So, it is a general DHCP issue not really specific to 3315id. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of David W. Hankins > Sent: Wednesday, August 11, 2004 6:44 PM > To: dhcwg@ietf.org > Cc: rbhibbs@pacbell.net > Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 > > > On Wed, Aug 11, 2004 at 05:58:04PM -0400, Bernie Volz wrote: > > I believe this really is more appropriate in > > draft-ietf-dhc-implementation-*.txt, though the (01) draft > appears to > > have > > I don't have a copy of that draft, so I can only guess that > it attempts to clarify the server's behaviour in regards to > the original Client Identifier? > > How is that the right place for defining the expected > behaviour of the server when it encounters the v6 DUID from > v4 clients that previously were only identified by chaddr? > > Sure, if we decide not to go ahead with the v6 DUID (not > likely), I think reviving that draft would be noble, but...I > like the v6 DUID. > > > I think we should just define the sane and rational behaviour > we expect of the server when it encounters the mixed > identities, since we already appear to have a consensus on > what that should be. > > Sending the draft to RFC knowing full well we're going to > have to submit similar clarifying work on its contents later > seems like a lot more work to me. We could just avoid all that. > > -- > David W. Hankins "If you don't do it right the > first time, > Operations 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 Thu Aug 12 05:39:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16317; Thu, 12 Aug 2004 05:39:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvC1R-0006qj-M7; Thu, 12 Aug 2004 05:37:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvBxW-00069N-Hn for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 05:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15999 for ; Thu, 12 Aug 2004 05:33:16 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvC2S-0007vR-1T for dhcwg@ietf.org; Thu, 12 Aug 2004 05:38:24 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7C9VO2M025545; Thu, 12 Aug 2004 11:31:24 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7C9VLAU008525; Thu, 12 Aug 2004 11:31:21 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Aug 2004 11:31:21 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040812093121.GB8177@sverresborg.uninett.no> References: <200408030929.31655.jdq@lucent.com> <000201c4797e$2a5f37e0$46828182@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz , jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, Aug 11, 2004 at 11:12:16PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Tue, 3 Aug 2004 13:20:22 -0400, > >>>>> "Bernie Volz" said: > > > I too would recommend that this option only be used with stateless > > (Information-Request/Reply). It does not apply to stateful - in stateful, > > even if there are no T1/T2 times (i.e., no IA_NA option), the client will > > need to do something when it no longer has addresses so it will get new > > information from the server. I think stateless only might be too strict. One example I have in mind is: If a client sends a request message to obtain addresses and other config options and it does not get any addresses but receives other config data. Then the client may use those options and not make a Request/Information-Request, right? You say client needs to do something when it no longer has addresses, but if you have IPv4 addresses, and the only IPv6 DHCP server says it has no addresses, then I think it's ok for the client to just use what it got without switching to stateless mode, and at some later point make a new Request, still not using stateless mode. How about saying this instead?: The lifetime option is mainly intended for Stateless DHCP service as specified in RFC 3736. If the client receives IA Address options containing lifetimes, the lifetime option should be ignored. The client should get updated configuration data from the server when it renews the addresses. Another thing I'm wondering about is if T1, T2 are zero or infinity. I think the lifetime option might make sense then. In 3315 it says: If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind message, respectively, at the client's discretion. If you get e.g. 0, it might be good to have some sort of lifetime for the other data, and I guess you might then do renew/rebind when the lifetime expires. > I tend to agree. In addition to the above points, I'd like to point > out that in the stateful exchanges the server can initiate update by > Reconfigure - at least in theory. Yes, if clients support it... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 08:18:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26960; Thu, 12 Aug 2004 08:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEQ2-0001Qu-NF; Thu, 12 Aug 2004 08:10:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEMg-0000jP-M0 for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:07:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26528 for ; Thu, 12 Aug 2004 08:07:25 -0400 (EDT) Received: from [203.199.203.114] (helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvERY-0002Ux-9G for dhcwg@ietf.org; Thu, 12 Aug 2004 08:12:34 -0400 Received: from intotoinc.com ([192.168.5.51]) by brahma.intotoind.com (8.12.6/8.11.6) with ESMTP id i7CCDrP1002973; Thu, 12 Aug 2004 17:43:53 +0530 Message-ID: <411B5D73.9010804@intotoinc.com> Date: Thu, 12 Aug 2004 17:37:15 +0530 From: Senthil Kumar B User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernie Volz Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 - NO GO! References: <002001c47fec$c84326f0$d0412ca1@amer.cisco.com> In-Reply-To: <002001c47fec$c84326f0$d0412ca1@amer.cisco.com> X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.6 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: neumann@wu-wien.ac.at, dhcwg@ietf.org, srihary@cisco.com, exand@wu-wien.ac.at, "'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: , Content-Type: multipart/mixed; boundary="===============1099624753==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1099624753== Content-Type: multipart/alternative; boundary="------------050707060704030202010700" This is a multi-part message in MIME format. --------------050707060704030202010700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks a lot for you reply and please see my reply inline. Replies are in Blue color. Bernie Volz wrote: >I do *NOT* agree with the last call on this document! > >The current document is >http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt >and I assume that is really the one being last called and the one I'll >comment on (as there are significant differences between 00 and 01). > >First, I'd like to understand how they'll encode values such as 1080 into a >single byte: > > The Proxy Server Configuration entry consists of a sequence of > Protocol Type (p), Encoding (e), IP address and port. > > +--+--+--+--+--+--+--+--+ > |p |e |IP address |port | > +--+--+--+--+--+--+--+--+ > > The Protocol(p) and encodig (e) are on octet each; each IP address is >---------------------------------------^^ (I assume this is ONE octet each?) > four octets, and each port number is a two-octet integer encoded in > network byte order. > >And then: > > The protocol type(p) specifies the type of Protocol and MUST be > one of the following assigned numbers. > > +-------------------------------+ > | protocol | Number | > +-------------------------------+ > | HTTP | 80 | > +-------------------------------+ > | FTP | 21 | > +-------------------------------+ > | NNTP | 119 | > +-------------------------------+ > | Gopher | 70 | > +-------------------------------+ > | SSL | TBD | > +-------------------------------+ > | SOCKS | 1080 | > >1080 requires two bytes to encode. > I agree that the protocol should be 2 octets. Initially, I thought of getting these protocol types assigned by IANA. As per your earlier suggestion, I had changed it to standard protocol numbers, but forgot to update the document. Will change it. > >Later, the document goes on about: > > The format of the Proxy Server Configuration using Metadata type is: > > > p Len RDF Metadata for the Proxy > +-------+------+----------------------------------+ > | RDF | N | RDF | > +-------+------+----------------------------------+ > > >What is this and where does this go? Is this a new option? Is this encoded >in the existing option in some manner which I can't understand? > > >And, the option size would seem to exceed the 255 byte limit: "... giving a >total of 418 characters including the overhead", yet nothing is ever >mentioned about RFC 3396 (encoding long options). > If the protocol type field (first field in the tuple in p/e/IPADDR/port) has the value for RDF (as specified in the table), then it SHOULD be followed by the length (N) of the RDF payload. I agree that RFC 3396 needs to be referred here. Will do the changes. Please let me know if there are any further comments, so that i can update all at once and will submit a new version. > >So, I think this draft needs much further revision before I feel it would be >acceptable. > >Best regards, > >- Bernie > > > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >>On Behalf Of Ralph Droms >>Sent: Wednesday, August 11, 2004 3:15 PM >>To: dhcwg@ietf.org >>Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 >> >> >>This message announces a second WG last call on "DHCP Option >>for Proxy Server Configuration" >>. There was insufficient >>(that is, none) response to the first WG last call. This >>document can not be submitted to the IESG without positive >>response during the WG last call. This last call will >>conclude at 1700 EDT, 2004-08-27. >> >>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. >> >>"DHCP Option for Proxy Server Configuration" defines a >>Dynamic Host Configuration Protocol (DHCP) option that can be >>used to configure the TCP/IP host's Proxy Server >>configuration for standard protocols like HTTP, FTP, NNTP, >>SOCKS, Gopher, SLL and etc. Proxy servers provide controlled >>and efficient access to the Internet through the use of >>access control mechanisms for different types of user >>requests and caching frequently accessed information (Web >>pages and other files that might have been downloaded using >>FTP and other protocols). This draft is available as >> >> >http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.txt > >- Ralph Droms > > >_______________________________________________ >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 > > > --------------050707060704030202010700 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks a lot for you reply and please see my reply inline. Replies are in Blue color.

Bernie Volz wrote:
I do *NOT* agree with the last call on this document!

The current document is
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt
and I assume that is really the one being last called and the one I'll
comment on (as there are significant differences between 00 and 01).

First, I'd like to understand how they'll encode values such as 1080 into a
single byte:

   The Proxy Server Configuration entry consists of a sequence of 
   Protocol Type (p), Encoding (e), IP address and port. 
   	  
   	+--+--+--+--+--+--+--+--+
	|p |e |IP address |port |
	+--+--+--+--+--+--+--+--+

   The Protocol(p) and encodig (e) are on octet each; each IP address is
---------------------------------------^^ (I assume this is ONE octet each?)
   four octets, and each port number is a two-octet integer encoded in
   network byte order.

And then:

   The protocol type(p) specifies the type of Protocol and MUST be 
   one of the following assigned numbers.

       +-------------------------------+
       | protocol     |       Number   |
       +-------------------------------+
       |   HTTP       |         80     |
       +-------------------------------+
       |   FTP        |         21     |
       +-------------------------------+
       |   NNTP       |         119    |
       +-------------------------------+
       |   Gopher     |         70     |
       +-------------------------------+
       |   SSL        |         TBD    |
       +-------------------------------+
       |   SOCKS      |         1080   |
  
1080 requires two bytes to encode.

I agree that the protocol should be 2 octets. Initially, I thought of getting these protocol types assigned by IANA.

As per your earlier suggestion, I had changed it to standard protocol numbers, but forgot to update the document.

Will change it. 

Later, the document goes on about:

   The format of the Proxy Server Configuration using Metadata type is:


            p       Len        RDF Metadata for the Proxy    
   	 +-------+------+----------------------------------+
   	 |  RDF  |  N   |             RDF                  |
   	 +-------+------+----------------------------------+


What is this and where does this go? Is this a new option? Is this encoded
in the existing option in some manner which I can't understand?


And, the option size would seem to exceed the 255 byte limit: "... giving a
total of 418 characters including the overhead", yet nothing is ever
mentioned about RFC 3396 (encoding long options).
If the protocol type field (first field in the tuple in p/e/IPADDR/port) has the value for RDF (as specified in the table), 
then it SHOULD be followed by the length (N) of the RDF payload.

I agree that RFC 3396 needs to be referred here. Will do the changes.

Please let me know if there are any further comments, so that i can update all at once and will submit a new version.
 

So, I think this draft needs much further revision before I feel it would be
acceptable.

Best regards,

- Bernie

  
-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
On Behalf Of Ralph Droms
Sent: Wednesday, August 11, 2004 3:15 PM
To: dhcwg@ietf.org
Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00


This message announces a second WG last call on "DHCP Option 
for Proxy Server Configuration" 
<draft-ietf-dhc-proxyserver-opt-00>.  There was insufficient 
(that is, none) response to the first WG last call.  This 
document can not be submitted to the IESG without positive 
response during the WG last call.  This last call will 
conclude at 1700 EDT, 2004-08-27.

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.

"DHCP Option for Proxy Server Configuration" defines a 
Dynamic Host Configuration Protocol (DHCP) option that can be 
used to configure the TCP/IP host's Proxy Server 
configuration for standard protocols like HTTP, FTP, NNTP, 
SOCKS, Gopher, SLL and etc. Proxy servers provide controlled 
and efficient access to the Internet through the use of 
access control mechanisms for different types of user 
requests and caching frequently accessed information (Web 
pages and other files that might have been downloaded using 
FTP and other protocols).  This draft is available as 
    
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.txt

- Ralph Droms


_______________________________________________
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
--------------050707060704030202010700-- --===============1099624753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1099624753==-- From dhcwg-bounces@ietf.org Thu Aug 12 08:51:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28785; Thu, 12 Aug 2004 08:51:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvExe-0007IQ-S7; Thu, 12 Aug 2004 08:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEkd-0004RZ-SZ for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27608 for ; Thu, 12 Aug 2004 08:32:10 -0400 (EDT) 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.33) id 1BvEpa-0002pZ-J6 for dhcwg@ietf.org; Thu, 12 Aug 2004 08:37:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2004 05:35:43 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7CCVZq1008286; Thu, 12 Aug 2004 05:31:36 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-171.cisco.com [10.86.240.171]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU29688; Thu, 12 Aug 2004 08:31:33 -0400 (EDT) From: "Bernie Volz" To: "'Senthil Kumar B'" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 - NO GO! Date: Thu, 12 Aug 2004 08:31:32 -0400 Organization: Cisco Message-ID: <001501c48068$4d9c0080$6401a8c0@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <411B5D73.9010804@intotoinc.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: f31e050dc7ce62aeed70903f7da21012 Cc: neumann@wu-wien.ac.at, dhcwg@ietf.org, srihary@cisco.com, exand@wu-wien.ac.at, "'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: , Content-Type: multipart/mixed; boundary="===============1639510629==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1639510629== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C48046.C68BE720" This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C48046.C68BE720 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi: =20 IMHO, the design of this option is bad - what if you want a new protocol = and want it to have a encoding similar to RDF? You won't be able to do this because all clients and servers would need to be upgraded at once - = which is clearly not possible. =20 You need to think about a general format that will accommodate future = growth and do it in a backwards compatible manner. =20 Perhaps something like: 2-bytes protocol number 1-byte encoding variable number of data bytes depending on encoding =20 This is still not that great because you can't add a new encoding type without upgrading all clients and servers at once. Though, one of the = known encoding types could have the data contain a length in the first 2-bytes = to accommodate the RDF encoding. =20 A better format, though less compact, might be: Protocol number (2 bytes) Data length (1 or 2 bytes; 2 probably needed if RDF could be > 255 bytes) Data of length bytes =20 The data of length bytes for most protocols would be
. is likely a bad name for this = field in this case? =20 In this way, you can extend the future "encodings" because those that = don't know the "encoding" for a protocol number know what to do - they simply = skip the data (and they know how long it is). =20 It isn't as compact as the old encoding, but it is much more extensible. =20 - Bernie -----Original Message----- From: Senthil Kumar B [mailto:ksenthil@intotoinc.com]=20 Sent: Thursday, August 12, 2004 8:07 AM To: Bernie Volz Cc: 'Ralph Droms'; dhcwg@ietf.org; neumann@wu-wien.ac.at; = srihary@cisco.com; exand@wu-wien.ac.at Subject: Re: [dhcwg] dhc WG last call on = draft-ietf-dhc-proxyserver-opt-00 - NO GO! Thanks a lot for you reply and please see my reply inline. Replies are = in Blue color. Bernie Volz wrote: I do *NOT* agree with the last call on this document! The current document is http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt= and I assume that is really the one being last called and the one I'll comment on (as there are significant differences between 00 and 01). First, I'd like to understand how they'll encode values such as 1080 = into a single byte: The Proxy Server Configuration entry consists of a sequence of=20 Protocol Type (p), Encoding (e), IP address and port.=20 =20 +--+--+--+--+--+--+--+--+ |p |e |IP address |port | +--+--+--+--+--+--+--+--+ The Protocol(p) and encodig (e) are on octet each; each IP address is ---------------------------------------^^ (I assume this is ONE octet = each?) four octets, and each port number is a two-octet integer encoded in network byte order. And then: The protocol type(p) specifies the type of Protocol and MUST be=20 one of the following assigned numbers. +-------------------------------+ | protocol | Number | +-------------------------------+ | HTTP | 80 | +-------------------------------+ | FTP | 21 | +-------------------------------+ | NNTP | 119 | +-------------------------------+ | Gopher | 70 | +-------------------------------+ | SSL | TBD | +-------------------------------+ | SOCKS | 1080 | =20 1080 requires two bytes to encode. I agree that the protocol should be 2 octets. Initially, I thought of getting these protocol types assigned by IANA. As per your earlier suggestion, I had changed it to standard protocol numbers, but forgot to update the document. Will change it.=20 Later, the document goes on about: The format of the Proxy Server Configuration using Metadata type is: p Len RDF Metadata for the Proxy =20 +-------+------+----------------------------------+ | RDF | N | RDF | +-------+------+----------------------------------+ What is this and where does this go? Is this a new option? Is this = encoded in the existing option in some manner which I can't understand? And, the option size would seem to exceed the 255 byte limit: "... = giving a total of 418 characters including the overhead", yet nothing is ever mentioned about RFC 3396 (encoding long options). If the protocol type field (first field in the tuple in p/e/IPADDR/port) = has the value for RDF (as specified in the table), =20 then it SHOULD be followed by the length (N) of the RDF payload. I agree that RFC 3396 needs to be referred here. Will do the changes. Please let me know if there are any further comments, so that i can = update all at once and will submit a new version. So, I think this draft needs much further revision before I feel it = would be acceptable. Best regards, - Bernie =20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 On Behalf Of Ralph Droms Sent: Wednesday, August 11, 2004 3:15 PM To: dhcwg@ietf.org Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 This message announces a second WG last call on "DHCP Option=20 for Proxy Server Configuration"=20 . There was insufficient=20 (that is, none) response to the first WG last call. This=20 document can not be submitted to the IESG without positive=20 response during the WG last call. This last call will=20 conclude at 1700 EDT, 2004-08-27. Please respond to this WG last call. If you support=20 acceptance of the document without change, respond with a=20 simple acknowledgment, so that support for the document can=20 be assessed. "DHCP Option for Proxy Server Configuration" defines a=20 Dynamic Host Configuration Protocol (DHCP) option that can be=20 used to configure the TCP/IP host's Proxy Server=20 configuration for standard protocols like HTTP, FTP, NNTP,=20 SOCKS, Gopher, SLL and etc. Proxy servers provide controlled=20 and efficient access to the Internet through the use of=20 access control mechanisms for different types of user=20 requests and caching frequently accessed information (Web=20 pages and other files that might have been downloaded using=20 FTP and other protocols). This draft is available as=20 =20 http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.txt= - Ralph Droms _______________________________________________ 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 =20 ------=_NextPart_000_0016_01C48046.C68BE720 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi:
 
IMHO,=20 the design of this option is bad - what if you want a new protocol = and want=20 it to have a encoding similar to RDF? You won't be able to do this = because all=20 clients and servers would need to be upgraded at once - which is clearly = not=20 possible.
 
You=20 need to think about a general format that will accommodate future growth = and do=20 it in a backwards compatible manner.
 
Perhaps something like:
    2-bytes protocol number
    1-byte encoding
    variable number of data bytes depending on=20 encoding
 
This=20 is still not that great because you can't add a new encoding type = without=20 upgrading all clients and servers at once. Though, one of the known = encoding=20 types could have the data contain a length in the first 2-bytes to = accommodate=20 the RDF encoding.
 
A=20 better format, though less compact, might be:
    Protocol number (2 = bytes)
    Data length (1 or 2 bytes; 2 probably needed = if=20 RDF could be > 255 bytes)
    Data of length bytes
 
The=20 data of length bytes for most protocols would be=20 <encoding><address><port>. <encoding> is likely = a bad=20 name for this field in this case?
 
In=20 this way, you can extend the future "encodings" because those that don't = know=20 the "encoding" for a protocol number know what to do - they simply skip = the data=20 (and they know how long it is).
 
It=20 isn't as compact as the old encoding, but it is much more=20 extensible.
 
-=20 Bernie
-----Original Message-----
From: = Senthil Kumar B=20 [mailto:ksenthil@intotoinc.com]
Sent: Thursday, August 12, = 2004=20 8:07 AM
To: Bernie Volz
Cc: 'Ralph Droms'; = dhcwg@ietf.org;=20 neumann@wu-wien.ac.at; srihary@cisco.com;=20 exand@wu-wien.ac.at
Subject: Re: [dhcwg] dhc WG last call on = draft-ietf-dhc-proxyserver-opt-00 - NO GO!

Thanks = a lot=20 for you reply and please see my reply inline. Replies are in Blue=20 color.

Bernie Volz wrote:
I do *NOT* agree with the last call on this =
document!

The current document is
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-=
opt-01.txt
and I assume that is really the one being last called and the one I'll
comment on (as there are significant differences between 00 and 01).

First, I'd like to understand how they'll encode values such as 1080 =
into a
single byte:

   The Proxy Server Configuration entry consists of a sequence of=20
   Protocol Type (p), Encoding (e), IP address and port.=20
   	 =20
   	+--+--+--+--+--+--+--+--+
	|p |e |IP address |port |
	+--+--+--+--+--+--+--+--+

   The Protocol(p) and encodig (e) are on octet each; each IP address is
---------------------------------------^^ (I assume this is ONE octet =
each?)
   four octets, and each port number is a two-octet integer encoded in
   network byte order.

And then:

   The protocol type(p) specifies the type of Protocol and MUST be=20
   one of the following assigned numbers.

       +-------------------------------+
       | protocol     |       Number   |
       +-------------------------------+
       |   HTTP       |         80     |
       +-------------------------------+
       |   FTP        |         21     |
       +-------------------------------+
       |   NNTP       |         119    |
       +-------------------------------+
       |   Gopher     |         70     |
       +-------------------------------+
       |   SSL        |         TBD    |
       +-------------------------------+
       |   SOCKS      |         1080   |
 =20
1080 requires two bytes to encode.

I=20 agree that the protocol should be 2 octets. Initially, I thought of = getting=20 these protocol types assigned by IANA.

As per your earlier = suggestion,=20 I had changed it to standard protocol numbers, but forgot to update = the=20 document.

Will change it. 
Later, the document goes on about:

   The format of the Proxy Server Configuration using Metadata type is:


            p       Len        RDF Metadata for the Proxy   =20
   	 +-------+------+----------------------------------+
   	 |  RDF  |  N   |             RDF                  |
   	 +-------+------+----------------------------------+


What is this and where does this go? Is this a new option? Is this =
encoded
in the existing option in some manner which I can't understand?


And, the option size would seem to exceed the 255 byte limit: "... =
giving a
total of 418 characters including the overhead", yet nothing is ever
mentioned about RFC 3396 (encoding long =
options).
If the protocol type field (first field in the tuple = in=20 p/e/IPADDR/port) has the value for RDF (as specified in the = table), =20
then it SHOULD be followed by the length (N) of the RDF = payload.

I=20 agree that RFC 3396 needs to be referred here. Will do the=20 changes.

Please let me know if there are any further comments, = so that=20 i can update all at once and will submit a new version.
So, I think this draft needs much further revision before I feel it =
would be
acceptable.

Best regards,

- Bernie

  
-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=
=20
On Behalf Of Ralph Droms
Sent: Wednesday, August 11, 2004 3:15 PM
To: dhcwg@ietf.org
Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00


This message announces a second WG last call on "DHCP Option=20
for Proxy Server Configuration"=20
<draft-ietf-dhc-proxyserver-opt-00>.  There was insufficient=20
(that is, none) response to the first WG last call.  This=20
document can not be submitted to the IESG without positive=20
response during the WG last call.  This last call will=20
conclude at 1700 EDT, 2004-08-27.

Please respond to this WG last call.  If you support=20
acceptance of the document without change, respond with a=20
simple acknowledgment, so that support for the document can=20
be assessed.

"DHCP Option for Proxy Server Configuration" defines a=20
Dynamic Host Configuration Protocol (DHCP) option that can be=20
used to configure the TCP/IP host's Proxy Server=20
configuration for standard protocols like HTTP, FTP, NNTP,=20
SOCKS, Gopher, SLL and etc. Proxy servers provide controlled=20
and efficient access to the Internet through the use of=20
access control mechanisms for different types of user=20
requests and caching frequently accessed information (Web=20
pages and other files that might have been downloaded using=20
FTP and other protocols).  This draft is available as=20
    
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-=
opt-00.txt

- Ralph Droms


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/dhcwg
------=_NextPart_000_0016_01C48046.C68BE720-- --===============1639510629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1639510629==-- From dhcwg-bounces@ietf.org Thu Aug 12 08:52:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28858; Thu, 12 Aug 2004 08:52:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvExf-0007Io-BD; Thu, 12 Aug 2004 08:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvElE-0004dv-3z for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:32:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27640 for ; Thu, 12 Aug 2004 08:32:46 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvEq9-0002qE-II for dhcwg@ietf.org; Thu, 12 Aug 2004 08:37:55 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7CCVpld019613; Thu, 12 Aug 2004 07:31:51 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7CCVox23191; Thu, 12 Aug 2004 08:31:50 -0400 (EDT) From: Joe Quanaim To: Stig Venaas , "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 08:31:01 -0400 User-Agent: KMail/1.5.4 References: <200408030929.31655.jdq@lucent.com> <20040812093121.GB8177@sverresborg.uninett.no> In-Reply-To: <20040812093121.GB8177@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408120831.02326.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > On Wed, Aug 11, 2004 at 11:12:16PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > >>>>> On Tue, 3 Aug 2004 13:20:22 -0400, > > >>>>> "Bernie Volz" said: > > > > > > I too would recommend that this option only be used with stateless > > > (Information-Request/Reply). It does not apply to stateful - in > > > stateful, even if there are no T1/T2 times (i.e., no IA_NA option), the > > > client will need to do something when it no longer has addresses so it > > > will get new information from the server. > > I think stateless only might be too strict. > > One example I have in mind is: > > If a client sends a request message to obtain addresses and other config > options and it does not get any addresses but receives other config > data. Then the client may use those options and not make a > Request/Information-Request, right? You say client needs to do something > when it no longer has addresses, but if you have IPv4 addresses, and the > only IPv6 DHCP server says it has no addresses, then I think it's ok for > the client to just use what it got without switching to stateless mode, > and at some later point make a new Request, still not using stateless > mode. I am not sure that the lifetime option is necessary when using stateful. I would consider this example stateless because the client has not successfully negotiated any (IPv6) addresses. Here I think you are right, though, a client should use the lifetime option. If it has any addresses, I think it should ignore the lifetime option. > How about saying this instead?: > > The lifetime option is mainly intended for Stateless DHCP service as > specified in RFC 3736. If the client receives IA Address options > containing lifetimes, the lifetime option should be ignored. The > client should get updated configuration data from the server when it > renews the addresses. > > Another thing I'm wondering about is if T1, T2 are zero or infinity. I > think the lifetime option might make sense then. In 3315 it says: > > If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no > T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind > message, respectively, at the client's discretion. > > If you get e.g. 0, it might be good to have some sort of lifetime for > the other data, and I guess you might then do renew/rebind when the > lifetime expires. > Even if T1 and T2 are zero or infinity, you have the lifetime of the address to fall back on. RFC 3315 says: Note that an IA_NA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_NA have expired, the IA_NA can be considered as having expired. And says something similar for IA_TA's. There is still an issue when the lifetime of the address is set to infinity, but this seems like a special case and one that might be used intentionally for one time configuration. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 09:03:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29264; Thu, 12 Aug 2004 09:03:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvF0b-0007y9-R8; Thu, 12 Aug 2004 08:48:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEtL-0006Ig-DG for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:41:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28319 for ; Thu, 12 Aug 2004 08:41:10 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvEyI-000339-SH for dhcwg@ietf.org; Thu, 12 Aug 2004 08:46:19 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7CCeX2M009464; Thu, 12 Aug 2004 14:40:33 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7CCeVn5009024; Thu, 12 Aug 2004 14:40:31 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Aug 2004 14:40:31 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040812124031.GH8177@sverresborg.uninett.no> References: <200408030929.31655.jdq@lucent.com> <20040812093121.GB8177@sverresborg.uninett.no> <200408120831.02326.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408120831.02326.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Thu, Aug 12, 2004 at 08:31:01AM -0400, Joe Quanaim wrote: > Stig Venaas wrote: [...] > > I think stateless only might be too strict. > > > > One example I have in mind is: > > > > If a client sends a request message to obtain addresses and other config > > options and it does not get any addresses but receives other config > > data. Then the client may use those options and not make a > > Request/Information-Request, right? You say client needs to do something > > when it no longer has addresses, but if you have IPv4 addresses, and the > > only IPv6 DHCP server says it has no addresses, then I think it's ok for > > the client to just use what it got without switching to stateless mode, > > and at some later point make a new Request, still not using stateless > > mode. > > I am not sure that the lifetime option is necessary when using stateful. I > would consider this example stateless because the client has not successfully > negotiated any (IPv6) addresses. Here I think you are right, though, a > client should use the lifetime option. If it has any addresses, I think it > should ignore the lifetime option. OK, I can agree with you if you define stateless that way. I'm thinking of stateless as defined in RFC 3736 using only Information-Request/Reply. My point is that it might be useful to use it with Request/Reply as well. So, my suggested wording should be ok then I understand you correctly. > > How about saying this instead?: > > > > The lifetime option is mainly intended for Stateless DHCP service as > > specified in RFC 3736. If the client receives IA Address options > > containing lifetimes, the lifetime option should be ignored. The > > client should get updated configuration data from the server when it > > renews the addresses. > > > > Another thing I'm wondering about is if T1, T2 are zero or infinity. I > > think the lifetime option might make sense then. In 3315 it says: > > > > If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no > > T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind > > message, respectively, at the client's discretion. > > > > If you get e.g. 0, it might be good to have some sort of lifetime for > > the other data, and I guess you might then do renew/rebind when the > > lifetime expires. > > > > Even if T1 and T2 are zero or infinity, you have the lifetime of the address > to fall back on. RFC 3315 says: > > Note that an IA_NA has no explicit "lifetime" or "lease length" of > its own. When the valid lifetimes of all of the addresses in an > IA_NA have expired, the IA_NA can be considered as having expired. > > And says something similar for IA_TA's. There is still an issue when the > lifetime of the address is set to infinity, but this seems like a special > case and one that might be used intentionally for one time configuration. Right, sounds reasonable. Thanks, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 09:04:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29370; Thu, 12 Aug 2004 09:04:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvF19-0008BV-NP; Thu, 12 Aug 2004 08:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEwB-0006yx-De for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:44:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28473 for ; Thu, 12 Aug 2004 08:44:06 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvF18-00036l-RG for dhcwg@ietf.org; Thu, 12 Aug 2004 08:49:15 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2004 05:46:41 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CCgKCN003018; Thu, 12 Aug 2004 05:42:23 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-171.cisco.com [10.86.240.171]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU30277; Thu, 12 Aug 2004 08:43:27 -0400 (EDT) From: "Bernie Volz" To: , "'Stig Venaas'" , "'JINMEI Tatuya / ?$B?@L@C#:H'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 08:43:27 -0400 Organization: Cisco Message-ID: <002601c48069$f73b3330$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200408120831.02326.jdq@lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable If a server sets the T1/T2 times to infinity, it gets what it asked for = - the configuration is static FOREVER. This is one reason it would be an extremely bad idea to ever use these values. We added them for clarity = in the RFC, though never really figured they would be used in practice. The no address issue is an interested one. On a SOLICIT, the server is ONLY to return the Status Message response = with NoAddrAvail status. It is *NOT* supposed to return any configuration information!!! Though it is always possible that a subsequent REQUEST or RENEW/REBIND = would result in no addresses. However, in those cases the IA_NA is still = returned with T1 and T2 times and those would, IMHO, apply. (In these cases, the NoAddrAvail status is embedded *INSIDE* the IA_* options so these = options are still returned.) I suppose there is the case when a SOLICIT/REQUEST/RENEW/REBIND for an = IA_NA and IA_TA results in no addresses for a IA_NA and one or more addresses = for a IA_TA, in which case no T1/T2 times are provided - thought the IA_TA = does have lifetimes. But, all of this gets very messy fairly quickly. So, perhaps the easiest thing to do is to *ALWAYS* allow the LIFETIME = option - for stateful and stateless. A client *SHOULD* renew (etc) its = information whenver the shortest time expires - LIFETIME, T1, or lifetime on an = address (and the client needs a replacement address). If the client is stateful, = is uses RENEW (whether the client includes on or more IA_NAs if no T1 time = has expired is a matter of local policy - though it would seem reasonable = for me if it did since there's no harm in doing so). If a client is stateless, = it uses INFORMATION-REQUEST. This also makes server implementations easier since the T1/T2 times and "other-configuration-parameters" lifetime can be configured = independently and a server need not assure that no T1 time is greater than "other-configuration-parameters". - Bernie > -----Original Message----- > From: Joe Quanaim [mailto:jdq@lucent.com]=20 > Sent: Thursday, August 12, 2004 8:31 AM > To: Stig Venaas; JINMEI Tatuya / ?$B?@L@C#:H > Cc: dhcwg@ietf.org; tjc@ecs.soton.ac.uk; Bernie Volz > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > Stig Venaas wrote: > > On Wed, Aug 11, 2004 at 11:12:16PM +0900, JINMEI Tatuya /=20 > ?$B?@L@C#:H=20 > > wrote: > > > >>>>> On Tue, 3 Aug 2004 13:20:22 -0400, > > > >>>>> "Bernie Volz" said: > > > > > > > > I too would recommend that this option only be used=20 > with stateless=20 > > > > (Information-Request/Reply). It does not apply to stateful - in=20 > > > > stateful, even if there are no T1/T2 times (i.e., no IA_NA=20 > > > > option), the client will need to do something when it no longer=20 > > > > has addresses so it will get new information from the server. > > > > I think stateless only might be too strict. > > > > One example I have in mind is: > > > > If a client sends a request message to obtain addresses and other=20 > > config options and it does not get any addresses but receives other=20 > > config data. Then the client may use those options and not make a=20 > > Request/Information-Request, right? You say client needs to do=20 > > something when it no longer has addresses, but if you have IPv4=20 > > addresses, and the only IPv6 DHCP server says it has no addresses,=20 > > then I think it's ok for the client to just use what it got without=20 > > switching to stateless mode, and at some later point make a new=20 > > Request, still not using stateless mode. >=20 > I am not sure that the lifetime option is necessary when=20 > using stateful. I=20 > would consider this example stateless because the client has=20 > not successfully=20 > negotiated any (IPv6) addresses. Here I think you are right,=20 > though, a=20 > client should use the lifetime option. If it has any=20 > addresses, I think it=20 > should ignore the lifetime option. >=20 > > How about saying this instead?: > > > > The lifetime option is mainly intended for Stateless=20 > DHCP service as > > specified in RFC 3736. If the client receives IA Address options > > containing lifetimes, the lifetime option should be ignored. The > > client should get updated configuration data from the=20 > server when it > > renews the addresses. > > > > Another thing I'm wondering about is if T1, T2 are zero or=20 > infinity. I=20 > > think the lifetime option might make sense then. In 3315 it says: > > > > If T1 or T2 is set to 0 by the server (for an IA_NA) or=20 > there are no > > T1 or T2 times (for an IA_TA), the client may send a=20 > Renew or Rebind > > message, respectively, at the client's discretion. > > > > If you get e.g. 0, it might be good to have some sort of=20 > lifetime for=20 > > the other data, and I guess you might then do renew/rebind when the=20 > > lifetime expires. > > >=20 > Even if T1 and T2 are zero or infinity, you have the lifetime=20 > of the address=20 > to fall back on. RFC 3315 says: >=20 > Note that an IA_NA has no explicit "lifetime" or "lease length" of > its own. When the valid lifetimes of all of the addresses in an > IA_NA have expired, the IA_NA can be considered as having expired. >=20 > And says something similar for IA_TA's. There is still an=20 > issue when the=20 > lifetime of the address is set to infinity, but this seems=20 > like a special=20 > case and one that might be used intentionally for one time=20 > configuration. >=20 > Joe Quanaim. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 09:27:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00815; Thu, 12 Aug 2004 09:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFVx-0005db-Sw; Thu, 12 Aug 2004 09:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFMY-0003e3-Cv for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 09:11:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29867 for ; Thu, 12 Aug 2004 09:11:21 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvFRV-0003Y8-BH for dhcwg@ietf.org; Thu, 12 Aug 2004 09:16:30 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7CDAfku012719; Thu, 12 Aug 2004 08:10:42 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7CDAex06575; Thu, 12 Aug 2004 09:10:40 -0400 (EDT) From: Joe Quanaim To: Stig Venaas Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 09:10:40 -0400 User-Agent: KMail/1.5.4 References: <200408030929.31655.jdq@lucent.com> <200408120831.02326.jdq@lucent.com> <20040812124031.GH8177@sverresborg.uninett.no> In-Reply-To: <20040812124031.GH8177@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408120910.40182.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > So, my suggested wording should be ok then I understand you correctly. > > > > How about saying this instead?: > > > > > > The lifetime option is mainly intended for Stateless DHCP service as > > > specified in RFC 3736. If the client receives IA Address options > > > containing lifetimes, the lifetime option should be ignored. The > > > client should get updated configuration data from the server when it > > > renews the addresses. I think that this wording is good. It does not intermix the lifetime option among the various possible t1, t2, and address lifetimes which I think complicates. Thanks, Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 09:35:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01265; Thu, 12 Aug 2004 09:35:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFW2-0005gP-3z; Thu, 12 Aug 2004 09:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFOO-0003uy-UV for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 09:13:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29915 for ; Thu, 12 Aug 2004 09:13:15 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvFTM-0003Zj-MC for dhcwg@ietf.org; Thu, 12 Aug 2004 09:18:25 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7CDAY2M016961; Thu, 12 Aug 2004 15:10:34 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7CDAYUx009117; Thu, 12 Aug 2004 15:10:34 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Aug 2004 15:10:34 +0200 From: Stig Venaas To: Bernie Volz Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040812131034.GI8177@sverresborg.uninett.no> References: <200408120831.02326.jdq@lucent.com> <002601c48069$f73b3330$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002601c48069$f73b3330$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Thu, Aug 12, 2004 at 08:43:27AM -0400, Bernie Volz wrote: > If a server sets the T1/T2 times to infinity, it gets what it asked for - > the configuration is static FOREVER. This is one reason it would be an > extremely bad idea to ever use these values. We added them for clarity in > the RFC, though never really figured they would be used in practice. > > The no address issue is an interested one. > > On a SOLICIT, the server is ONLY to return the Status Message response with > NoAddrAvail status. It is *NOT* supposed to return any configuration > information!!! > > Though it is always possible that a subsequent REQUEST or RENEW/REBIND would > result in no addresses. However, in those cases the IA_NA is still returned > with T1 and T2 times and those would, IMHO, apply. (In these cases, the > NoAddrAvail status is embedded *INSIDE* the IA_* options so these options > are still returned.) > > I suppose there is the case when a SOLICIT/REQUEST/RENEW/REBIND for an IA_NA > and IA_TA results in no addresses for a IA_NA and one or more addresses for > a IA_TA, in which case no T1/T2 times are provided - thought the IA_TA does > have lifetimes. > > But, all of this gets very messy fairly quickly. > > So, perhaps the easiest thing to do is to *ALWAYS* allow the LIFETIME option > - for stateful and stateless. A client *SHOULD* renew (etc) its information > whenver the shortest time expires - LIFETIME, T1, or lifetime on an address > (and the client needs a replacement address). If the client is stateful, is > uses RENEW (whether the client includes on or more IA_NAs if no T1 time has > expired is a matter of local policy - though it would seem reasonable for me > if it did since there's no harm in doing so). If a client is stateless, it > uses INFORMATION-REQUEST. > > This also makes server implementations easier since the T1/T2 times and > "other-configuration-parameters" lifetime can be configured independently > and a server need not assure that no T1 time is greater than > "other-configuration-parameters". This is more in line with my original idea for lifetime. I've started improving the draft, and I now have these paragraphs: The lifetime option specifies a lifetime for all configuration data contained in other options in an advertise or reply message that have no associated lifetime. If any of the options have an associated lifetime of their own which is shorter than the lifetime option value, then that should take precedence. Or in other words, the lifetime option specifies an upper bound for how long the client should wait before attempting to renew the data. If there are options with a shorter lifetime or the client has other reasons for requesting data from the DHCP server, then it should also update the data covered by the lifetime option. I think this should pretty much cover what you say and is in line with my own thinking. After that I have the paragraph: The lifetime option is mainly intended for Stateless DHCP service as specified in [RFC 3736]. If the client receives IA Address options containing lifetimes, the lifetime option should be ignored. The client should get updated configuration data from the server when it renews the addresses. Personally I'm happy to remove that again. I guess we should try to come to some consensus before I do more writing. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 10:13:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03833; Thu, 12 Aug 2004 10:13:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG6R-0004hq-Gz; Thu, 12 Aug 2004 09:58:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG1b-0003RQ-Pp for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 09:53:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02233 for ; Thu, 12 Aug 2004 09:53:46 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvG6T-0004LY-1r for dhcwg@ietf.org; Thu, 12 Aug 2004 09:58:56 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Aug 2004 06:54:49 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7CDr3pp012878; Thu, 12 Aug 2004 06:53:04 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU34874; Thu, 12 Aug 2004 09:53:02 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 09:53:01 -0400 Organization: Cisco Message-ID: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040812131034.GI8177@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I do think you should remove that last paragraph: > The lifetime option is mainly intended for Stateless DHCP service as > specified in [RFC 3736]. If the client receives IA Address options > containing lifetimes, the lifetime option should be ignored. The > client should get updated configuration data from the server when it > renews the addresses. It confuses the issue. Perhaps something like: The primary motivation for the lifetime option is for situations where no lifetime (or renewal time) is communicated to the client, such as for Stateless DHCP service as specified in [RFC 3736]. However, it applies to both stateful and stateless DHCP clients and is an upper bound for when a client should initiate renewal of at least its non-address based configuration parameters - a stateful client MAY renew its addresses at the same time and SHOULD always get updated configuration data from the server when it renews any addresses. One difference between Stateful and Stateless clients with regards to this option is that a Stateful client that does not receive this option MUST NOT apply the default lifetime. - Bernie > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no] > Sent: Thursday, August 12, 2004 9:11 AM > To: Bernie Volz > Cc: jdq@lucent.com; 'JINMEI Tatuya / ?$B?@L@C#:H'; > dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt > > > On Thu, Aug 12, 2004 at 08:43:27AM -0400, Bernie Volz wrote: > > If a server sets the T1/T2 times to infinity, it gets what it asked > > for - the configuration is static FOREVER. This is one > reason it would > > be an extremely bad idea to ever use these values. We added > them for > > clarity in the RFC, though never really figured they would > be used in > > practice. > > > > The no address issue is an interested one. > > > > On a SOLICIT, the server is ONLY to return the Status > Message response > > with NoAddrAvail status. It is *NOT* supposed to return any > > configuration information!!! > > > > Though it is always possible that a subsequent REQUEST or > RENEW/REBIND > > would result in no addresses. However, in those cases the IA_NA is > > still returned with T1 and T2 times and those would, IMHO, > apply. (In > > these cases, the NoAddrAvail status is embedded *INSIDE* the IA_* > > options so these options are still returned.) > > > > I suppose there is the case when a > SOLICIT/REQUEST/RENEW/REBIND for an > > IA_NA and IA_TA results in no addresses for a IA_NA and one or more > > addresses for a IA_TA, in which case no T1/T2 times are provided - > > thought the IA_TA does have lifetimes. > > > > But, all of this gets very messy fairly quickly. > > > > So, perhaps the easiest thing to do is to *ALWAYS* allow > the LIFETIME > > option > > - for stateful and stateless. A client *SHOULD* renew (etc) > its information > > whenver the shortest time expires - LIFETIME, T1, or > lifetime on an address > > (and the client needs a replacement address). If the client > is stateful, is > > uses RENEW (whether the client includes on or more IA_NAs > if no T1 time has > > expired is a matter of local policy - though it would seem > reasonable for me > > if it did since there's no harm in doing so). If a client > is stateless, it > > uses INFORMATION-REQUEST. > > > > This also makes server implementations easier since the T1/T2 times > > and "other-configuration-parameters" lifetime can be configured > > independently and a server need not assure that no T1 time > is greater > > than "other-configuration-parameters". > > This is more in line with my original idea for lifetime. I've > started improving the draft, and I now have these paragraphs: > > The lifetime option specifies a lifetime for all configuration data > contained in other options in an advertise or reply > message that have > no associated lifetime. If any of the options have an associated > lifetime of their own which is shorter than the lifetime > option value, > then that should take precedence. > > Or in other words, the lifetime option specifies an upper bound for > how long the client should wait before attempting to renew > the data. > If there are options with a shorter lifetime or the client > has other > reasons for requesting data from the DHCP server, then it > should also > update the data covered by the lifetime option. > > I think this should pretty much cover what you say and is in > line with my own thinking. > > After that I have the paragraph: > > The lifetime option is mainly intended for Stateless DHCP > service as > specified in [RFC 3736]. If the client receives IA Address options > containing lifetimes, the lifetime option should be ignored. The > client should get updated configuration data from the > server when it > renews the addresses. > > Personally I'm happy to remove that again. I guess we should > try to come to some consensus before I do more writing. > > Stig > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 10:38:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05873; Thu, 12 Aug 2004 10:38:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvGbs-0000Ny-61; Thu, 12 Aug 2004 10:31:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvGYQ-00085L-86 for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 10:27:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05231 for ; Thu, 12 Aug 2004 10:27:40 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvGdN-0004va-Cz for dhcwg@ietf.org; Thu, 12 Aug 2004 10:32:50 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7CEOLLG006713; Thu, 12 Aug 2004 09:24:21 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7CEOKx03603; Thu, 12 Aug 2004 10:24:20 -0400 (EDT) From: Joe Quanaim To: "Bernie Volz" , "'Stig Venaas'" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 10:18:57 -0400 User-Agent: KMail/1.5.4 References: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> In-Reply-To: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408121018.57077.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie Volz wrote: > I do think you should remove that last paragraph: > > > The lifetime option is mainly intended for Stateless DHCP service as > > specified in [RFC 3736]. If the client receives IA Address options > > containing lifetimes, the lifetime option should be ignored. The > > client should get updated configuration data from the server when it > > renews the addresses. I would prefer leaving the paragraph. > It confuses the issue. > > Perhaps something like: > > The primary motivation for the lifetime option is for situations where > no lifetime (or renewal time) is communicated to the client, such as for > Stateless DHCP service as specified in [RFC 3736]. However, it applies > to both stateful and stateless DHCP clients and is an upper bound for > when a client should initiate renewal of at least its non-address based > configuration parameters - a stateful client MAY renew its addresses at > the same time and SHOULD always get updated configuration data from the > server when it renews any addresses. > > One difference between Stateful and Stateless clients with regards > to this option is that a Stateful client that does not receive this > option MUST NOT apply the default lifetime. > As noted, the motivation of the lifetime option is to ensure stateless clients receive current configuration information. As such, I think keeping it out of stateful configuration is the simplest approach. As we have discussed, stateful configuration already has several variables to manipulate client behavior. I do not see much gain in adding another. Still, it's not that complex a change. If I am outvoted, so be it. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 12:00:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10612; Thu, 12 Aug 2004 12:00:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvHwO-0003H9-Le; Thu, 12 Aug 2004 11:56:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvHrZ-0002HQ-2j for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 11:51:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10276 for ; Thu, 12 Aug 2004 11:51:30 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvHwX-0006Td-CW for dhcwg@ietf.org; Thu, 12 Aug 2004 11:56:42 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 4ABEAB241F; Thu, 12 Aug 2004 08:51:00 -0700 (PDT) Date: Thu, 12 Aug 2004 08:51:00 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040812155100.GA38172@isc.org> References: <20040810224111.GA722@isc.org> <002201c47fee$47009120$d0412ca1@amer.cisco.com> <20040811224350.GJ746@isc.org> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rbhibbs@pacbell.net 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="===============0572279068==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0572279068== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 06:34:13PM -0700, Ted Lemon wrote: > different IP addresses. There is no harm in this, unless you are=20 > concerned about excessive IP address consumption. If you are=20 I'm really confused by this statement, because I thought I documented the harm. Go back and read what I said about Win XPe please? I never answerd your other mail because your recommendations about alternative actions equally surprised me...they won't work. You also seem fixated upon having the PXE client send 'a different client identifier' when in fact the problem is that it doesn't send that option at all, and the problem would be made worse if it ever did. So there's quite a lot of confusion floating around already. To briefly restate, an undocumented behaviour which fixes this problem without user intervention or new PXE clients has arisen in the majority of DHCP servers. At least one client has arisen (Win XPe) that relies upon this behaviour in order to boot...at all. So it is no longer about over-consumption of addresses. That issue, and the way that those servers choose to solve it for their paying customers, is what has led us now to this impasse. > concerned about that, there are stopgap solutions to get you over the=20 > hump until the last of those PXE cards dies a well-deserved death. That will not happen. I don't think that any iteration of 'dumb bootstrap device' will ever learn anything more complicated than it absolutely has to, for darn good reasons. And I really doubt that Microsoft will ever make something like a client identifier a user-configurable option (like Apple does). --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG5HjcXeLeWu2vmoRAsiRAJ9fO1vsmTDNfPbQkUf+J1lwiOcveQCfTo18 6cfvga8EMC7WTMr/il43U5s= =LHbN -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- --===============0572279068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0572279068==-- From dhcwg-bounces@ietf.org Thu Aug 12 12:32:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13122; Thu, 12 Aug 2004 12:32:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvINq-0001Tm-2W; Thu, 12 Aug 2004 12:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvICA-0006Y0-QY for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 12:12:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11365 for ; Thu, 12 Aug 2004 12:12:48 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIH7-0006qh-76 for dhcwg@ietf.org; Thu, 12 Aug 2004 12:18:00 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 12 Aug 2004 12:21:12 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CGCDCf003681; Thu, 12 Aug 2004 12:12:13 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU47032; Thu, 12 Aug 2004 12:12:12 -0400 (EDT) From: "Bernie Volz" To: , "'Stig Venaas'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 12:12:12 -0400 Organization: Cisco Message-ID: <002a01c48087$20483580$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200408121018.57077.jdq@lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable My impression is that people want it for stateful as well - or at least = not to restrict it from being used there. I was where you are - keeping it for stateless only. But there are some = edge cases where stateful clients might not receive any times or might = receive extremely long times (though I think these are really exceptional = cases). I also think it is easier configuration wise to just allow an = administrator on a server to configure this option and not have code in the server not = to send this for a stateful REPLY (or on a client to ignore it). Though I = guess we could place the responsibility on the client not to include it in the = ORO when stateful. So, I've changed my mind - allow it for stateful as well. BTW, shouldn't we improve the langauge in the draft regarding the ORO? = It is currently: 3.1. Client behaviour A client supporting this option MAY include it in the Option Request Option (ORO) when sending messages to the DHCP server that allows ORO to be included. I would suggest we change it to: 3.1. Client behaviour A client supporting this option MUST include it in the Option Request Option (ORO) when sending SOLICIT, REQUEST, RENEW, REBIND, and INFORMATION-REQUEST messages to the DHCP server. If the consenus is to keep this for stateless only, then it would read: 3.1. Client behaviour A client supporting this option MUST include it in the Option Request Option (ORO) when sending INFORMATION-REQUEST messages to the DHCP server. A client MUST NOT include this option in an ORO option in any other messages. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Joe Quanaim > Sent: Thursday, August 12, 2004 10:19 AM > To: Bernie Volz; 'Stig Venaas' > Cc: dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > Bernie Volz wrote: > > I do think you should remove that last paragraph: > > > > > The lifetime option is mainly intended for Stateless=20 > DHCP service as > > > specified in [RFC 3736]. If the client receives IA=20 > Address options > > > containing lifetimes, the lifetime option should be=20 > ignored. The > > > client should get updated configuration data from the=20 > server when it > > > renews the addresses. >=20 > I would prefer leaving the paragraph. >=20 > > It confuses the issue. > > > > Perhaps something like: > > > > The primary motivation for the lifetime option is for=20 > situations where > > no lifetime (or renewal time) is communicated to the=20 > client, such as for > > Stateless DHCP service as specified in [RFC 3736].=20 > However, it applies > > to both stateful and stateless DHCP clients and is an=20 > upper bound for > > when a client should initiate renewal of at least its=20 > non-address based > > configuration parameters - a stateful client MAY renew=20 > its addresses at > > the same time and SHOULD always get updated configuration=20 > data from the > > server when it renews any addresses. > > > > One difference between Stateful and Stateless clients with regards > > to this option is that a Stateful client that does not=20 > receive this > > option MUST NOT apply the default lifetime. > > >=20 > As noted, the motivation of the lifetime option is to ensure=20 > stateless clients=20 > receive current configuration information. As such, I think=20 > keeping it out=20 > of stateful configuration is the simplest approach. As we=20 > have discussed,=20 > stateful configuration already has several variables to=20 > manipulate client=20 > behavior. I do not see much gain in adding another. >=20 > Still, it's not that complex a change. If I am outvoted, so be it. >=20 > Joe Quanaim. >=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 From dhcwg-bounces@ietf.org Thu Aug 12 12:36:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13402; Thu, 12 Aug 2004 12:36:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvINr-0001Ux-FS; Thu, 12 Aug 2004 12:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIDe-00074h-G2 for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 12:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11466 for ; Thu, 12 Aug 2004 12:14:20 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIId-0006sd-1o for dhcwg@ietf.org; Thu, 12 Aug 2004 12:19:32 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 3FE25B241F; Thu, 12 Aug 2004 09:13:50 -0700 (PDT) Date: Thu, 12 Aug 2004 09:13:50 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040812161350.GB38172@isc.org> References: <20040811224350.GJ746@isc.org> <001701c48015$49540c50$6401a8c0@amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <001701c48015$49540c50$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rbhibbs@pacbell.net 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="===============0399846592==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0399846592== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 10:37:18PM -0400, Bernie Volz wrote: > Perhaps I'm not understanding the issue fully, but isn't this a > problem if a client first sends NO client identifier (to boot) > and then (once the O/S is running) sends a client identifier? Yes, precisely. > IMHO, is a general problem whenever this switch from no-client > identifier to client identifier happens. So, it is a general > DHCP issue not really specific to 3315id. I understand now, thanks Bernie. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG5c9cXeLeWu2vmoRAicsAJ4mg1EXRp3+1V/JpZzXjz6x4YefdgCgpSo4 AY5a2U5ADN9cUesMiotF+p8= =+xRi -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- --===============0399846592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0399846592==-- From dhcwg-bounces@ietf.org Thu Aug 12 12:38:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13622; Thu, 12 Aug 2004 12:38:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIQT-0001xC-U9; Thu, 12 Aug 2004 12:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvII2-0000EP-Du for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 12:18:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12019 for ; Thu, 12 Aug 2004 12:18:51 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIN0-00070i-Op for dhcwg@ietf.org; Thu, 12 Aug 2004 12:24:04 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CGGtCN021593; Thu, 12 Aug 2004 09:17:01 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU47393; Thu, 12 Aug 2004 12:16:59 -0400 (EDT) From: "Bernie Volz" To: "'David W. Hankins'" , Subject: RE: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Thu, 12 Aug 2004 12:16:59 -0400 Organization: Cisco Message-ID: <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040812155100.GA38172@isc.org> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: rbhibbs@pacbell.net 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > And I really doubt that > Microsoft will ever make something like a client identifier a > user-configurable option (like Apple does). Well, I don't know about Win XPe, but see http://support.microsoft.com/default.aspx?scid=kb;en-us;172408. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of David W. Hankins > Sent: Thursday, August 12, 2004 11:51 AM > To: dhcwg@ietf.org > Cc: rbhibbs@pacbell.net > Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 > > > On Wed, Aug 11, 2004 at 06:34:13PM -0700, Ted Lemon wrote: > > different IP addresses. There is no harm in this, unless you are > > concerned about excessive IP address consumption. If you are > > I'm really confused by this statement, because I thought I > documented the harm. > > Go back and read what I said about Win XPe please? I never > answerd your other mail because your recommendations about > alternative actions equally surprised me...they won't work. > You also seem fixated upon having the PXE client send 'a > different client identifier' when in fact the problem is that > it doesn't send that option at all, and the problem would be > made worse if it ever did. > > So there's quite a lot of confusion floating around already. > > > To briefly restate, an undocumented behaviour which fixes > this problem without user intervention or new PXE clients has > arisen in the majority of DHCP servers. At least one client > has arisen (Win XPe) that relies upon this behaviour in order > to boot...at all. > > So it is no longer about over-consumption of addresses. That > issue, and the way that those servers choose to solve it for > their paying customers, is what has led us now to this impasse. > > > concerned about that, there are stopgap solutions to get > you over the > > hump until the last of those PXE cards dies a well-deserved death. > > That will not happen. > > I don't think that any iteration of 'dumb bootstrap device' > will ever learn anything more complicated than it absolutely > has to, for darn good reasons. And I really doubt that > Microsoft will ever make something like a client identifier a > user-configurable option (like Apple does). > > -- > David W. Hankins "If you don't do it right the > first time, > Operations 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 Thu Aug 12 13:06:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15970; Thu, 12 Aug 2004 13:06:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIhZ-00064O-0R; Thu, 12 Aug 2004 12:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIXa-0003FI-Mk; Thu, 12 Aug 2004 12:34:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13244; Thu, 12 Aug 2004 12:34:56 -0400 (EDT) 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.33) id 1BvIcY-0007MH-Ug; Thu, 12 Aug 2004 12:40:08 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2004 09:38:29 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7CGY9jd025811; Thu, 12 Aug 2004 09:34:18 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU48815; Thu, 12 Aug 2004 12:34:08 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Date: Thu, 12 Aug 2004 12:34:08 -0400 Organization: Cisco Message-ID: <002e01c4808a$30c86c60$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4.3.2.7.2.20040812092026.01feaa88@flask.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.4 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] RE: Stateful != M , Stateless != O 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Seems to me that: If M is set(1), a client able to do stateful, does stateful (or full 3315) and ignores the O bit. This client can always fall back to stateless if it receives a NoAddrAvail status for a SOLICIT (as per 17.1.3) and receives no other ADVERTISEs it can use. Though this behavior isn't clearly spelled out in 3315 (either in 17.1.2 or 17.1.3) and may be something we want to consider in a future revision of 3315. Perhaps this behavior could even be controlled by the O bit - if the O bit is set, the client SHOULD try stateless (INFORMATION-REQUEST). If either M or O is set, a client able to do stateless (either full 3315 or 3736), does stateless. - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Ralph Droms > Sent: Thursday, August 12, 2004 9:26 AM > To: ipv6@ietf.org > Subject: RE: Stateful != M , Stateless != O > > > Seems to me it would be useful to allow both M and O flag on. > > While, in theory, the support for the subset of DHCPv6 > indicated by the O bit is implied by the support for all of > DHCPv6 indicated by the M bit, it seems there would be little > harm in advertising both. > > Some hosts may choose to use both the Request message > exchange for address assignment and the Information-Request > message exchange for other information. For example, an > application may need other configuration information that was > not supplied during the initial Request message exchange, > requiring a subsequent Informaton-Request message exchange > for that information. There are DHCPv4 hosts that work this > way today. > > - Ralph > > At 12:32 PM 8/11/2004 -0400, Soliman Hesham wrote: > >I have a silly question below. > > > > > > > I now feel I get understanding the point...to make it > sure, > let > > me try > to rephrase that. > > > > > > Assume we have a "stateful" DHCPv6 server (that > implements RFC3315) > > > running. The server should support both > > > Solicit/Advertise/Request/Reply(/and Renew) and > > > Information-request/Reply exchanges. > > > > > > Then the administrator would send Router Advertisement with > > > the M flag > > > being ON and the O flag being OFF. (The O flag is OFF > since there is > > > no server that only supports RFC3736). > > > >=> Couldn't the admin turn on the O flag in this case too? > >The host doesn't know which RFC the server supports so > >I don't see what harm will be done if the O flag is turned on > >independently of the setting of the M flag. > > > > > Now consider a host that only implements (the client side > of) > > RFC3736, > configures global addresses via stateless address > > autoconfiguration > (assuming the RAs provide global prefixes for > > this), and wants to > configure recursive DNS server > addresses using > > RFC3736. However, > since the O flag is OFF in advertised > RAs, the > > host would not be able > to invoke the RFC3736 procedure and > > therefore cannot configure DNS > server addresses. This > should be a > > suboptimal scenario. > > > >=> Right, but there is no need to have the O flag off. To me > RFC 3736 > >is something useful for server vendors and should not be associated > >with setting the O flag. > > > >Hesham > > > >=========================================================== > >This email may contain confidential and privileged material for the > >sole use > > of the intended recipient. Any review or distribution by > others is strictly > > prohibited. If you are not the intended recipient please > contact the sender > > and delete all copies. > >=========================================================== > > > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 13:37:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18365; Thu, 12 Aug 2004 13:37:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJT4-0000w6-DZ; Thu, 12 Aug 2004 13:34:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJAH-000529-Fn for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 13:14:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16664 for ; Thu, 12 Aug 2004 13:14:54 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvJFG-0008OR-Fs for dhcwg@ietf.org; Thu, 12 Aug 2004 13:20:07 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id D8B24B241F; Thu, 12 Aug 2004 10:14:24 -0700 (PDT) Date: Thu, 12 Aug 2004 10:14:24 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040812171424.GF38172@isc.org> References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rbhibbs@pacbell.net 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="===============1249173619==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1249173619== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9crTWz/Z+Zyzu20v" Content-Disposition: inline --9crTWz/Z+Zyzu20v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 12:16:59PM -0400, Bernie Volz wrote: > Well, I don't know about Win XPe, but see > http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;172408. Sorry for not being clear, that's what I meant by "(like Apple does)". Anything that starts with "run regedit" doesn't count, since that does not pass the "Can you talk my Mom through doing it?" test. Faced with that exact problem, of talking people no more computer-savvy than an average person through doing it (no offence to average people), ISP's using our server software choose to hack the server code and *remove client id's entirely from packets they receive* rather than to talk customers through making their windows boxes stop sending client-id's to match their PXE instances. Which, obviously, is very painful to hear, and why I'm keen to see the more pallateable solution very clearly defined in rfc. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --9crTWz/Z+Zyzu20v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG6VwcXeLeWu2vmoRAhyjAKCjygkcYtMslVsTm9E/KU82zvus9ACeI5PX NM/O2T0pDqsnaM65Za3gZEI= =mnzN -----END PGP SIGNATURE----- --9crTWz/Z+Zyzu20v-- --===============1249173619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1249173619==-- From dhcwg-bounces@ietf.org Thu Aug 12 14:35:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21463; Thu, 12 Aug 2004 14:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKLK-0003LR-NN; Thu, 12 Aug 2004 14:30:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKJf-0002vo-UX for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 14:28:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21047 for ; Thu, 12 Aug 2004 14:28:42 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvKOd-0001L2-JP for dhcwg@ietf.org; Thu, 12 Aug 2004 14:33:54 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 476501B209C; Thu, 12 Aug 2004 13:26:20 -0500 (CDT) In-Reply-To: <20040812171424.GF38172@isc.org> References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> <20040812171424.GF38172@isc.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Thu, 12 Aug 2004 11:28:34 -0700 To: "David W. Hankins" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, rbhibbs@pacbell.net 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 12, 2004, at 10:14 AM, David W. Hankins wrote: > ISP's using our server software choose to hack the server code and > *remove > client id's entirely from packets they receive* rather than to talk > customers through making their windows boxes stop sending client-id's > to > match their PXE instances. You have ISP customers that do PXE booting on behalf of customers? I am now deeply confused. As far as talking your mother through it, when would you ever want to talk your mother through setting up a diskless boot client? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From fgjmf@msn.com Thu Aug 12 16:16:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01518; Thu, 12 Aug 2004 16:16:11 -0400 (EDT) Received: from i3ed63bef.versanet.de ([62.214.59.239]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BvM4f-0004Tx-Gr; Thu, 12 Aug 2004 16:21:25 -0400 Received: from 19.60.102.234 by 62.214.59.239; Fri, 13 Aug 2004 00:14:52 +0300 Message-ID: From: "Margery Cook" Reply-To: "Margery Cook" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Best software prices. Date: Thu, 12 Aug 2004 20:07:52 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--956307184432702" X-IP: 247.193.160.83 X-Spam-Score: 4.6 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----956307184432702 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable TOP quality software:

Special Offer #1:
Windows XP P= rofessional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adob= e - Photoshop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macromed= ia Dreamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here=











?2N47A3zVjC9Xk2yedifice|dhci= pv6-archive@ietf.org">or un*su*bs*cr*ibe =20 ----956307184432702-- From dhcwg-bounces@ietf.org Thu Aug 12 18:18:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13090; Thu, 12 Aug 2004 18:18:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvNqF-0003SJ-Vu; Thu, 12 Aug 2004 18:14:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvNmq-0000zd-Ph for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 18:11:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12304 for ; Thu, 12 Aug 2004 18:10:59 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvNrp-0007zC-U5 for dhcwg@ietf.org; Thu, 12 Aug 2004 18:16:15 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 0B70BB241F; Thu, 12 Aug 2004 15:10:25 -0700 (PDT) Date: Thu, 12 Aug 2004 15:10:24 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040812221024.GH38172@isc.org> References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> <20040812171424.GF38172@isc.org> <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> Mime-Version: 1.0 In-Reply-To: <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: rbhibbs@pacbell.net 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="===============1876932648==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1876932648== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B8ONY/mu/bqBak9m" Content-Disposition: inline --B8ONY/mu/bqBak9m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 11:28:34AM -0700, Ted Lemon wrote: > You have ISP customers that do PXE booting on behalf of customers? I=20 > am now deeply confused. I'm sorry, you have every right to be confused, my mind jumped here halfway through the conversation and I never made mention of this. I shouldn't have mentioned it, it's not important to this discussion. But it's an amusing story nonetheless. A lone geek at a small ISP trying to horn in on the broadband space. She has an arrangement with the last-mile supplier so that she gets DHCP relays installed in every customer-prem. She limits the number of leases to a fixed number per each relay-agent id suboption. Customers pay more for more leases. Now imagine that one of the two following cases starts happening. 1) A misconfigured boot-order, or a system with an unusual (not IDE, some kinda add-in card that maybe only gets tried in boot order because the 'boot other devices' option set to enabled in the bios) arrangement as a hard drive, results in having 'network' on its boot-order before the hard drive in question. PXE will try to boot, fail, then boot the system on the hard drive. This might be repeated for multiple network interfaces, if any, but hopefully the customer doesn't have them all plugged in. 2) A person with PXE clients at home has failed to segregate the broadcast domain of their broadband connection's set-top box with their pxe clients and the DHCP server they rely upon. The PXE client boots from the local dhcpd, then later from the ISP's, but her DHCP server still sends out OFFERs. Now imagine the lease limitation is full once the all the customer's systems are online. But the extra lease OFFERed to the PXE client means they are denied booting before all their systems are up. When I said "ISP's using our software", I should have just left it at "users of", since I don't actually know from where the patches came. I just know that they're out there, and people are using it (and being guided to use it)...it's just that this ISP thing latched into my memory at that moment and I wasn't exercising enough restraint at the keyboard. Sorry about that, common disease for me I'm afraid. > As far as talking your mother through it, > when would you ever want to talk your mother through setting up a > diskless boot client? I was specifically referring to 'setting and unsetting the client identifier' for reasons that are now hopefully somewhat less muddy. There are lines in the sand everywhere as to whose burden it is to bear support costs. So long as the answer is 'regedit', the burden of support is too great a cost for people to choose to bear. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --B8ONY/mu/bqBak9m Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG+rQcXeLeWu2vmoRAt75AKCtWiuQQabuvjhIcrRQFjv3tLH+5ACfROqw Aqa3gCXOc1cfXdWNHFAoPvo= =+fn6 -----END PGP SIGNATURE----- --B8ONY/mu/bqBak9m-- --===============1876932648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1876932648==-- From dhcwg-bounces@ietf.org Thu Aug 12 18:53:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15249; Thu, 12 Aug 2004 18:53:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvOJt-0003JA-Eh; Thu, 12 Aug 2004 18:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvOHo-0002Oq-De for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 18:43:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14535 for ; Thu, 12 Aug 2004 18:43:01 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvOMp-0008W4-Ux for dhcwg@ietf.org; Thu, 12 Aug 2004 18:48:17 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 646A41B24C1; Thu, 12 Aug 2004 17:40:40 -0500 (CDT) In-Reply-To: <20040812221024.GH38172@isc.org> References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> <20040812171424.GF38172@isc.org> <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> <20040812221024.GH38172@isc.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Thu, 12 Aug 2004 15:42:55 -0700 To: "David W. Hankins" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit In the case of a PXE boot like the one you describe, the right answer for the ISP is to configure the DHCP server to put PXE clients in a special class, and not offer service to clients in that class. Then you don't have to worry about inappropriately responding to PXE clients that you can't actually configure. This is really the same problem as the well-known RAS server problem. One nice side effect of ignoring PXE clients is that since the boot now has to time out, the user will probably notice the incorrect boot order. This probably goes unnoticed with the current configuration because PXE probably gives up immediately when it gets a response with no PXE boot information in it. An additional advantage of PXE is that it gives up quickly, so you don't have to worry about endless DHCPDISCOVERs in your log files. My experience over the years is that when customers feel they need to hack the DHCP server sources, it's usually because they aren't aware that it's already possible to configure the server to address the problem they're having. I think this is true somewhat independently of the server implementation - it's certainly just as true of the Nominum DHCP server as it is of the ISC DHCP server, and I think it's also true of Cisco's DHCP server. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dptoi@msn.com Fri Aug 13 00:37:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02837; Fri, 13 Aug 2004 00:37:07 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvTtZ-00061e-64; Fri, 13 Aug 2004 00:42:26 -0400 Received: from [221.162.59.213] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BvSx4-0007BI-KZ; Thu, 12 Aug 2004 23:41:59 -0400 Received: from 60.0.62.0 by web097.mail.yahoo.com; Fri, 13 Aug 2004 00:33:55 -0500 Message-ID: From: "Jo Pratt" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive s0ftware at incredibly low prices Date: Fri, 13 Aug 2004 04:33:55 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--85927298643802360817" X-CS-IP: 172.124.36.160 X-Spam-Score: 9.1 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----85927298643802360817 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable TOP quality software:

Special Offer #1:
Windows XP = Professional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe - = Photoshop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macromedia = Dreamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here<= /a>











?2N47A3zVjC9Xk2ypullover= |dhcipv6-archive@ietf.org">or un*su*bs*cr*ibe =20 ----85927298643802360817-- From dhcwg-bounces@ietf.org Fri Aug 13 07:38:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07629; Fri, 13 Aug 2004 07:38:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvaFN-0007ik-Fy; Fri, 13 Aug 2004 07:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvaCE-0007L0-BO; Fri, 13 Aug 2004 07:26:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07014; Fri, 13 Aug 2004 07:26:04 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvaHM-0004F2-Hy; Fri, 13 Aug 2004 07:31:25 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2D00F04UCUZ4@mailout2.samsung.com>; Fri, 13 Aug 2004 20:24:30 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2D00GKHUCTST@mailout2.samsung.com>; Fri, 13 Aug 2004 20:24:29 +0900 (KST) Received: from SYAM ([107.108.71.123]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2D003UEUCLVC@mmp2.samsung.com>; Fri, 13 Aug 2004 20:24:29 +0900 (KST) Date: Fri, 13 Aug 2004 16:54:40 +0530 From: Syam Madanapalli To: Radhakrishnan Suryanarayanan , Tatuya / ???? JINMEI Message-id: <014b01c48128$226229b0$7b476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <005e01c47faf$a61058b0$7b476c6b@sisodomain.com> <411C4A29.5010200@eng.monash.edu.au> <06a001c480f4$b1314bf0$40476c6b@sisodomain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Cc: Gregory Daley , dhcwg@ietf.org, ipv6@ietf.org, Pekka Savola , Soohong Daniel Park Subject: [dhcwg] Re: comments on draft-daniel-ipv6-ra-mo-flags-00.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Jinmei, > > I don't mind adding the appendix as long we just describe possible > issues (if any) and do NOT try to provide workaround like combining > router/parameters. That looks fine, we will just describe the issues and leave the implementation details to the developers. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 13 08:27:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10997; Fri, 13 Aug 2004 08:27:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvb2V-0008PI-80; Fri, 13 Aug 2004 08:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvarR-0006aa-Fj for dhcwg@megatron.ietf.org; Fri, 13 Aug 2004 08:08:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10113 for ; Fri, 13 Aug 2004 08:08:40 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvawb-0005HK-ED for dhcwg@ietf.org; Fri, 13 Aug 2004 08:14:01 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7DC882M023105; Fri, 13 Aug 2004 14:08:08 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7DC87Mx012667; Fri, 13 Aug 2004 14:08:07 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 13 Aug 2004 14:08:07 +0200 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Message-ID: <20040813120807.GA12587@sverresborg.uninett.no> References: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> <20040810110500.GB2802@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 10, 2004 at 09:45:36AM -0700, Ted Lemon wrote: > Stig, maybe you can explain for me how it is less complicated to supply > multicast prefixes than it is to do stateful allocation - I don't get > it. With multicast prefixes, the client either has to take its OK, I'll try. > chances with the possibility of a collision, which seems quite likely > (random number generators are usually deterministic, not random, and > getting one that uses any real source of entropy is difficult, not > easy), or it has to do some kind of duplicate address detection, which > also seems difficult, not easy. I don't have a clue what the likelihood is. But just to make it clear, we're talking of a 32-bit number. So question is how likely is it for two hosts/applications on the same link to pick the same 32-bit value. I agree that some form of DAD could be needed, and I agree it's not easy. I've been wondering slightly if the DAD in Neighbor Discovery could be reused, but anyway, it's a big complication, I agree. > In contrast, while stateful address allocation requires slightly more > work on the server side (in the sense that the server has to remember > which address it allocated), it's much easier on the client side - the > client gets a specific address, doesn't need a good RNG, and doesn't > need to do multicast DAD. The additional complexity of remembering > which IP address we gave to the client is well-understood technology, > requiring no innovations and risking no accidental DoS attacks from > broken clients. The stateful approach introduces some other complexity on the client that I'm concerned about. The main issue, is that it's the application that needs the addresses. You need some additional infrastructure/middleware on the host. Either the application needs to act as DHCP client (there are big issues with that) or the application needs some standardized way of communicating with the DHCP client. Basically the application will need to signal to the DHCP client that it needs an address, and that must be returned back to the client. Also, while the application is running, the DHCP client must renew the address on behalf of the application. I've been trying to think through how to actually implement this, and it's not easy. I must say though, that coming up with a general solution to how applications can interact with DHCP might be interesting. If we instead used the stateless prefix announcement solution we may need to solve the DAD issue, but there are some advantages. o For link-local multicast, it would be possible to generate link unique multicast addresses with no need for DHCP servers or routers. o For unicast-prefix-based addressing (RFC 3306) you can generate a /96 multicast prefix from the links unicast /64 prefix and then using RNG plus possibly DAD you can come up with prefixes to use on the link. This can be done without DHCP. o For Embedded-RP the application will need to learn the prefix from somewhere. But the system could learn the prefix once (from DHCP, from config file or whatever) and all the applications use the same. You can perhaps compare it to how applications use resolv.conf on unix and how it might be configured from DHCP or other systems. > History suggests that DHCP server implementations are more likely to be > correct than DHCP client implementations, perhaps because there is less > risk of monoculture in the interoperability testing done by a DHCP > server vendor than by a DHCP client vendor (a client vendor will > typically test against a single server, whereas a server vendor will > typically have many different clients to test against). Right > So if it makes sense to do something like this, I would vote for doing > it in a stateful manner, not a stateless manner. I think something like this is needed. Currently I'm in favour of stateless, but I'm trying to explore both possibilities. I'm not sure myself which one is superior. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 13 19:57:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26491; Fri, 13 Aug 2004 19:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvlt6-0001hp-PU; Fri, 13 Aug 2004 19:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvlsa-0001Z8-Un for dhcwg@megatron.ietf.org; Fri, 13 Aug 2004 19:54:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26351 for ; Fri, 13 Aug 2004 19:54:35 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvlxq-0001y1-GR for dhcwg@ietf.org; Fri, 13 Aug 2004 20:00:03 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 16:52:07 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 16:53:07 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 16:54:01 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 16:53:12 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 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] RE: mboned:draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Fri, 13 Aug 2004 16:54:02 -0700 Message-ID: Thread-Topic: [dhcwg] RE: mboned:draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcSBNTNNMNEeczIYREih2wEeuolyngAWnZlQ From: "Dave Thaler" To: "Stig Venaas" , "Ted Lemon" X-OriginalArrivalTime: 13 Aug 2004 23:53:12.0653 (UTC) FILETIME=[B18147D0:01C48190] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Stig Venaas writes: > If we instead used the stateless prefix announcement solution we may > need to solve the DAD issue, but there are some advantages. >=20 > o For link-local multicast, it would be possible to generate link > unique multicast addresses with no need for DHCP servers or routers. Right. This is what=20 http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-04 .txt does. > o For unicast-prefix-based addressing (RFC 3306) you can generate a > /96 multicast prefix from the links unicast /64 prefix and then > using RNG plus possibly DAD you can come up with prefixes to use on > the link. This can be done without DHCP. Right. > o For Embedded-RP the application will need to learn the prefix from > somewhere. But the system could learn the prefix once (from DHCP, > from config file or whatever) and all the applications use the same. > You can perhaps compare it to how applications use resolv.conf on > unix and how it might be configured from DHCP or other systems. And you need a DAD mechanism for address selection within the prefix, as with 3306 addresses. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 16 08:31:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00445; Mon, 16 Aug 2004 08:31:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwgbc-00074C-T2; Mon, 16 Aug 2004 08:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwgPG-0005s1-Qp for dhcwg@megatron.ietf.org; Mon, 16 Aug 2004 08:16:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29746 for ; Mon, 16 Aug 2004 08:16:05 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwgV3-0000Ew-1Z for dhcwg@ietf.org; Mon, 16 Aug 2004 08:22:06 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4164:cd3:c762:127d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4C30715263; Mon, 16 Aug 2004 21:15:57 +0900 (JST) Date: Mon, 16 Aug 2004 21:15:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <20040812093121.GB8177@sverresborg.uninett.no> References: <200408030929.31655.jdq@lucent.com> <000201c4797e$2a5f37e0$46828182@amer.cisco.com> <20040812093121.GB8177@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz , jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 12 Aug 2004 11:31:21 +0200, >>>>> Stig Venaas said: >> > I too would recommend that this option only be used with stateless >> > (Information-Request/Reply). It does not apply to stateful - in stateful, >> > even if there are no T1/T2 times (i.e., no IA_NA option), the client will >> > need to do something when it no longer has addresses so it will get new >> > information from the server. > I think stateless only might be too strict. > One example I have in mind is: > If a client sends a request message to obtain addresses and other config > options and it does not get any addresses but receives other config > data. Then the client may use those options and not make a > Request/Information-Request, right? A quick response for clarification: if you mean the case where the client receives an Advertise message containing a NoAddrsAvail status code, I don't think the client may use other configuration options (moreover, I don't think the client ever receives such configuration options in this case). RFC3315 is not so explicit in such a case, but it requires the client just to ignore such an Advertise message: The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. (Section 17.1.3) and the server to send minimum information to indicate the error: If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with ^^^^ code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. (Section 17.2.2) Again, this is just for clarification, and may be irrelevant to the main point of this discussion. 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 Aug 16 14:56:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22319; Mon, 16 Aug 2004 14:56:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmUC-00084S-7b; Mon, 16 Aug 2004 14:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmNa-0006w2-Ob for dhcwg@megatron.ietf.org; Mon, 16 Aug 2004 14:38:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21153 for ; Mon, 16 Aug 2004 14:38:45 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwmTQ-0006Yp-Bb for dhcwg@ietf.org; Mon, 16 Aug 2004 14:44:49 -0400 Received: from [81.200.65.118] (dhcp-118.wl.nominum.com [81.200.65.118]) by toccata.fugue.com (Postfix) with ESMTP id 207321B20E6; Mon, 16 Aug 2004 13:35:44 -0500 (CDT) In-Reply-To: <000d01c47f06$9dc56ff0$d0412ca1@amer.cisco.com> References: <000d01c47f06$9dc56ff0$d0412ca1@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7FD2BE8F-EFB3-11D8-9348-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Mon, 16 Aug 2004 11:38:43 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie, the problem I have with the complex model for the DHCPv6 FQDN option is that I can't imagine any of the scenarios you describe ever having a meaning in practice. A computer is a computer. It has a name. One name. If you give it multiple names, that doesn't have any meaning, generally speaking. The exception is when you are configuring a single computer to present more than one identity on the network. In this case, it makes sense that each identity would have its own name. So I think it makes sense to have a one-to-one mapping between names and identity associations. I do not think it makes sense to break it down below this point. Let's consider some of the scenarios you've proposed. First, let's consider number four, which you say you consider most likely. In this case, the client has a single identity, and gets both a globally-scoped address and a locally-scoped address. So what does it make sense to do here? We have several options: 1. Publish the name with the global address. 2. Publish the name with both the global and site-local address. 3. Publish two names, one for the global address and one for the local address. So what's going to fail in case 1? Let's say some clients get site-local addresses, and some get global _and_ site-local addresses. If we only publish the global address, can a client with only a site-local address exchange packets with the client with the global address? I think it can, as long as they are both at the same site (which is the only case that matters). So I think that this solution works, and we don't need to do anything further. What fails in case 2? We've published a site-local address in a global namespace. If a host outside of the site wants to contact the host using the name, how does it know that the site-local address is not local? It doesn't. We can't control which address it tries to connect to, and many network clients do not try to connect to every address - they just try to connect to the first one, which DNS is required to alternate. So what we would get, from the perspective of a naive user, would be intermittent failures. Not good. What about case 3? Case 3 works, but now you have to tell people about two different names. Why would you want that, when one name will do? So I really think that case 1 is how you want to do things, and this is easy and matches the one name per IAID model very nicely. As far as whether temporary and public addresses are part of the same IA or not, why not let it be that if you want for some reason to publish your temporary address, the way you do it is under a separate IAID? Why add complexity when there's a way to do it that's less complex? If a site is multihomed and wants to use different names for different addresses, I'm skeptical that it's something we need to think about here and now. While it's true that this is a possible scenario, I think the complexity that addressing this problem adds to the current draft is unacceptable. I would like to see this problem actually happen in the real world, and have that drive a new standardization effort, rather than trying to guess how people are going to want to solve this problem when we've never seen it happen in the real world, and really don't have a basis for talking about what need we're addressing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 16 19:52:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22672; Mon, 16 Aug 2004 19:52:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwrCj-0007ZY-40; Mon, 16 Aug 2004 19:47:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwr38-0003AJ-Vw for dhcwg@megatron.ietf.org; Mon, 16 Aug 2004 19:37:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22052 for ; Mon, 16 Aug 2004 19:37:57 -0400 (EDT) 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.33) id 1Bwr92-0007F5-5x for dhcwg@ietf.org; Mon, 16 Aug 2004 19:44:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2004 16:42:25 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7GNbMwM009182; Mon, 16 Aug 2004 16:37:22 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKW60661; Mon, 16 Aug 2004 19:36:06 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" Subject: RE: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt Date: Mon, 16 Aug 2004 19:36:06 -0400 Organization: Cisco Message-ID: <005001c483e9$cd040d70$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-reply-to: <7FD2BE8F-EFB3-11D8-9348-000A95D9C74C@nominum.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted: Thanks for your feedback on this issue. Others, please chime in with your thoughts/opinions. One possibility is to allow both. The simple case just has the client FQDN option in the IA_*-options = field for both the client and server and one name applies to all of the = address. The complex case (if the server determines that a unique name is = required for each address) it can use the alternate form - putting the client = FQDN option into the IAaddr-options field (as currently specified). Since it requires client (and server) support for the complex case, we = can use a "flag" bit to allow the client to specify whether it can support = the complex case. By default (if the bit is 0), the client (and server) can = only use the simple case. If the bit is set, it is up to the server to = determine whether to use the simple or complex case, based on the addresses and = the configuration. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Monday, August 16, 2004 2:39 PM > To: Bernie Volz > Cc: dhcwg@ietf.org > Subject: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt >=20 >=20 > Bernie, the problem I have with the complex model for the DHCPv6 FQDN=20 > option is that I can't imagine any of the scenarios you describe ever=20 > having a meaning in practice. A computer is a computer. It has a=20 > name. One name. If you give it multiple names, that doesn't have=20 > any meaning, generally speaking. The exception is when you are=20 > configuring a single computer to present more than one=20 > identity on the=20 > network. In this case, it makes sense that each identity would have=20 > its own name. >=20 > So I think it makes sense to have a one-to-one mapping between names=20 > and identity associations. I do not think it makes sense to=20 > break it=20 > down below this point. Let's consider some of the scenarios you've=20 > proposed. First, let's consider number four, which you say you=20 > consider most likely. >=20 > In this case, the client has a single identity, and gets both a=20 > globally-scoped address and a locally-scoped address. So=20 > what does it=20 > make sense to do here? We have several options: >=20 > 1. Publish the name with the global address. > 2. Publish the name with both the global and site-local=20 > address. 3. Publish two names, one for the global address and=20 > one for the local=20 > address. >=20 > So what's going to fail in case 1? Let's say some clients get=20 > site-local addresses, and some get global _and_ site-local=20 > addresses. =20 > If we only publish the global address, can a client with only a=20 > site-local address exchange packets with the client with the global=20 > address? I think it can, as long as they are both at the same site=20 > (which is the only case that matters). So I think that this=20 > solution=20 > works, and we don't need to do anything further. >=20 > What fails in case 2? We've published a site-local address in a=20 > global namespace. If a host outside of the site wants to=20 > contact the=20 > host using the name, how does it know that the site-local address is=20 > not local? It doesn't. We can't control which address it tries to=20 > connect to, and many network clients do not try to connect to every=20 > address - they just try to connect to the first one, which DNS is=20 > required to alternate. So what we would get, from the=20 > perspective of=20 > a naive user, would be intermittent failures. Not good. >=20 > What about case 3? Case 3 works, but now you have to tell people=20 > about two different names. Why would you want that, when one name=20 > will do? So I really think that case 1 is how you want to=20 > do things,=20 > and this is easy and matches the one name per IAID model very nicely. >=20 > As far as whether temporary and public addresses are part of the same=20 > IA or not, why not let it be that if you want for some reason to=20 > publish your temporary address, the way you do it is under a separate=20 > IAID? Why add complexity when there's a way to do it that's less=20 > complex? >=20 > If a site is multihomed and wants to use different names for=20 > different=20 > addresses, I'm skeptical that it's something we need to think about=20 > here and now. While it's true that this is a possible scenario, I=20 > think the complexity that addressing this problem adds to the current=20 > draft is unacceptable. I would like to see this problem actually=20 > happen in the real world, and have that drive a new standardization=20 > effort, rather than trying to guess how people are going to want to=20 > solve this problem when we've never seen it happen in the real world,=20 > and really don't have a basis for talking about what need we're=20 > addressing. >=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 From dhcwg-bounces@ietf.org Tue Aug 17 04:51:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01609; Tue, 17 Aug 2004 04:51:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwze2-0006E0-VO; Tue, 17 Aug 2004 04:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwzal-0005NI-J4 for dhcwg@megatron.ietf.org; Tue, 17 Aug 2004 04:45:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01320 for ; Tue, 17 Aug 2004 04:45:13 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwzgi-0007gq-Jv for dhcwg@ietf.org; Tue, 17 Aug 2004 04:51:26 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:fd13:3c53:7410:a99a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 141771525D; Tue, 17 Aug 2004 17:45:06 +0900 (JST) Date: Tue, 17 Aug 2004 17:45:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: jdq@lucent.com Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <200408121018.57077.jdq@lucent.com> References: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> <200408121018.57077.jdq@lucent.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz , "'Stig Venaas'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 12 Aug 2004 10:18:57 -0400, >>>>> Joe Quanaim said: >> The primary motivation for the lifetime option is for situations where >> no lifetime (or renewal time) is communicated to the client, such as for >> Stateless DHCP service as specified in [RFC 3736]. However, it applies >> to both stateful and stateless DHCP clients and is an upper bound for >> when a client should initiate renewal of at least its non-address based >> configuration parameters - a stateful client MAY renew its addresses at >> the same time and SHOULD always get updated configuration data from the >> server when it renews any addresses. >> >> One difference between Stateful and Stateless clients with regards >> to this option is that a Stateful client that does not receive this >> option MUST NOT apply the default lifetime. > As noted, the motivation of the lifetime option is to ensure stateless clients > receive current configuration information. As such, I think keeping it out > of stateful configuration is the simplest approach. As we have discussed, > stateful configuration already has several variables to manipulate client > behavior. I do not see much gain in adding another. It's not a strong opinion, but I'd also still prefer to restrict the use of the lifetime option to the stateless case. The reasons are: - even if it might be true that the client can use stateful exchanges without having addresses or infinite T1/T2 timers for other configurations only, it should be a very minor case (I'm pretty sure that everyone agrees on this - whether still want to allow such usage or not). In my understanding, the sense of RFC3315 is that "if you can get an address, you may get other information. If you cannot get an address, then give up any possible information." In fact, Section 18.1.8 says [...] If the client receives no addresses in any of the IAs, it may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to obtain other configuration information only. but the RFC does not (explicitly) allow the client to continue to use other information configuration than addresses. What you are going to achieve in the scenario of the lifetime option with the stateful case seems to contradict the original sense, IMO. - recalling that we rejected the idea of multiple lifetime options for multiple configuration parameters, it's odd to me that we are now going to have T1/T2 as well as the lifetime option (I was happy with rejecting the idea of multiple lifetimes, BTW). If we applied the same logic, we could simply use an appropriate T1 value to implement controlled update of the other configuration information. Again, it's true that stateful exchanges can provide no finite timers, but, as I said in the above bullet, it's very minor or even almost-unexpected use case in my understanding. - as I pointed out in my first message, we'll have to define all the details, most of which are boring corner cases (but the implementors would be unhappy if we didn't define those). I know some of you are now trying to address those, and trying to minimize the complexity of the specification. However, right now I'm not sure if it really makes sense, considering the usage case of stateful+lifetime is minor. I admit this is a tradeoff issue, and perhaps we need to end up discussing details to make a clear consensus. - one thing I'm concerned about which is related to the above point: there is already a non-address IA that has a notion of timeout: IA_PD. So, we'll probably have to consider the combination of IA_PD and the lifetime option. Moreover, the lifetime option document may need to be generic enough to prepare for any future stateful resources that has a notion of timeout. > Still, it's not that complex a change. If I am outvoted, so be it. Same here. Though I'm still skeptical about the benefit of the use case of stateful+lifetime, considering the possible complexity, I can live with that if the specification is crystal clear about all the details. 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 Aug 18 13:39:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24472; Wed, 18 Aug 2004 13:39:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxUDl-0003iz-RX; Wed, 18 Aug 2004 13:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxU8z-0003AZ-G5 for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 13:22:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23362 for ; Wed, 18 Aug 2004 13:22:34 -0400 (EDT) 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.33) id 1BxUFE-0001yu-H5 for dhcwg@ietf.org; Wed, 18 Aug 2004 13:29:05 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2004 10:27:12 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7IHLkTt002912; Wed, 18 Aug 2004 10:21:46 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA23987; Wed, 18 Aug 2004 10:21:52 -0700 (PDT) Message-Id: <4.3.2.7.2.20040818121846.02798f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Aug 2004 12:23:28 -0500 To: mjs@cisco.com, Ted.Lemon@nominum.com From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.3 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org Subject: [dhcwg] Nit with "Authentication Suboption" ID 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Mark/Ted The 3rd paragraph of section 4 is: "Four bits are reserved for future use. These bits SHOULD be set to zero, and MUST be not be used when the suboption is processed. " I believe this should end with: "... and MUST NOT be used when the suboption is processed." with "NOT" as normative and the first "be" removed - as it seems to be there in error comments welcome cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 18 13:45:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24930; Wed, 18 Aug 2004 13:45:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxURr-0006Hh-PH; Wed, 18 Aug 2004 13:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxUP2-0005gl-5B for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 13:39:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24443 for ; Wed, 18 Aug 2004 13:38:50 -0400 (EDT) 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.33) id 1BxUUu-0002Js-HW for dhcwg@ietf.org; Wed, 18 Aug 2004 13:45:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2004 10:41:29 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7IHa8Tt023548; Wed, 18 Aug 2004 10:36:09 -0700 (PDT) Received: from mjs-xp.cisco.com (dhcp-10-86-160-98.cisco.com [10.86.160.98]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKX86042; Wed, 18 Aug 2004 13:36:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20040818133216.0262bec8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Aug 2004 13:35:12 -0400 To: "James M. Polk" From: Mark Stapp In-Reply-To: <4.3.2.7.2.20040818121846.02798f00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dhcwg@ietf.org, Ted.Lemon@nominum.com Subject: [dhcwg] Re: Nit with "Authentication Suboption" ID 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org thanks for catching that. I've updated the source, and I'll include that fix when we spin the next rev. Regards, Mark At 12:23 PM 8/18/2004 -0500, James M. Polk wrote: >Mark/Ted > >The 3rd paragraph of section 4 is: > >"Four bits are reserved for future use. These bits SHOULD be set to zero, >and MUST be not be used when the suboption is processed. " > >I believe this should end with: > > "... and MUST NOT be used when the suboption is processed." > >with "NOT" as normative > >and the first "be" removed - as it seems to be there in error > >comments welcome > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 18 18:09:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24961; Wed, 18 Aug 2004 18:09:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxYOj-0003xW-S3; Wed, 18 Aug 2004 17:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxY73-00005k-JV for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 17:36:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22212 for ; Wed, 18 Aug 2004 17:36:51 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxYDJ-0003FL-St for dhcwg@ietf.org; Wed, 18 Aug 2004 17:43:24 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7ILaIq18580 for ; Wed, 18 Aug 2004 17:36:18 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 17:36:19 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92025D75B9@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: dhcwg@ietf.org Date: Wed, 18 Aug 2004 17:36:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [dhcwg] questions on RFC 3046 and RFC 3527 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello all, I have some questions regarding RFC3046 and RFC3527: Q1. RFC3046 defines the Relay Agent Information Option. One of the sub option for this option is Agent Remote ID Sub-option. A possible value for this sub-option can be "the remote IP address of a point-to-point link". RFC3527 defines another sub-option for Relay Agent Information Option called Link selection sub-option. The possible value for this sub-option can be the subnet (of the link) of the DHCP client. The question is, why the IP address in "Agent Remote ID Sub-option" can't be used to identify the subnet of link for the DHCP client? Why there was a need for two separate sub-options to convey the same thing? Q2. RFC3046 says: " 2.2 Server Operation DHCP servers unaware of the Relay Agent Information option will ignore the option upon receive and will not echo it back on responses. This is the specified server behavior for unknown options. " RFC3527 says: " When the DHCP server is allocating an address and this sub-option is present, then the DHCP server MUST allocate the address on either: o the subnet specified in the link-selection sub-option, or; o a subnet on the same link (also known as a network segment) as the subnet specified by the link-selection sub-option. " The confusion is: RFC3527 seems to mandate the DHCP server to assign IP address based on link-selection sub-option when this sub-option is present in the received request, but RFC3046 says that the entire Relay Agent Information option can be ignored by the DHCP server if it is not supported. Could someone clarify this? Regards, Kuntal _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 18 18:42:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27714; Wed, 18 Aug 2004 18:42:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZ5W-00042c-Vl; Wed, 18 Aug 2004 18:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxYzf-0002ta-C2 for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 18:33:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27035 for ; Wed, 18 Aug 2004 18:33:16 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxZ5u-0004TS-Sy for dhcwg@ietf.org; Wed, 18 Aug 2004 18:39:50 -0400 Received: from homerdmz.incognito.com ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.30) id 1BxYz0-0002jr-9f; Wed, 18 Aug 2004 15:32:38 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 15:32:04 -0700 Message-ID: From: "Kostur, Andre" To: "'Kuntal Chowdhury'" , dhcwg@ietf.org Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Wed, 18 Aug 2004 15:32:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 2.3 (++) X-Spam-Report: Spam detection software, running on the system "chimera.incognito.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. > Hello all, > > I have some questions regarding RFC3046 and RFC3527: > > Q1. > > RFC3046 defines the Relay Agent Information Option. One of > the sub option > for this option is Agent Remote ID Sub-option. A possible > value for this > sub-option can be "the remote IP address of a point-to-point link". [...] Content analysis details: (2.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML 1.5 HTML_MESSAGE BODY: HTML included in message X-Spam-Score: 0.8 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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="===============1903579874==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1903579874== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48573.2FCB91A0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C48573.2FCB91A0 Content-Type: text/plain; charset="iso-8859-1" > Hello all, > > I have some questions regarding RFC3046 and RFC3527: > > Q1. > > RFC3046 defines the Relay Agent Information Option. One of > the sub option > for this option is Agent Remote ID Sub-option. A possible > value for this > sub-option can be "the remote IP address of a point-to-point link". Note the phrasing that a _possible_ value for this sub-option.... > RFC3527 defines another sub-option for Relay Agent > Information Option called > Link selection sub-option. The possible value for this > sub-option can be the > subnet (of the link) of the DHCP client. > > The question is, why the IP address in "Agent Remote ID > Sub-option" can't be > used to identify the subnet of link for the DHCP client? Why > there was a > need for two separate sub-options to convey the same thing? Because the RemoteID isn't necessarily an IP address? At least one well-known standard (DOCSIS) sepcifies that the Remote ID is the MAC address of the cable modem, and not an IP address. > Q2. > > RFC3046 says: > > " > 2.2 Server Operation > > DHCP servers unaware of the Relay Agent Information option will > ignore the option upon receive and will not echo it back on > responses. This is the specified server behavior for unknown > options. > " > RFC3527 says: > > " > When the DHCP server is allocating an address and this > sub-option is > present, then the DHCP server MUST allocate the address on either: > > o the subnet specified in the link-selection sub-option, or; > > o a subnet on the same link (also known as a network > segment) as > the subnet specified by the link-selection sub-option. > " > > The confusion is: RFC3527 seems to mandate the DHCP server to > assign IP > address based on link-selection sub-option when this > sub-option is present > in the received request, but RFC3046 says that the entire Relay Agent > Information option can be ignored by the DHCP server if it is > not supported. > Could someone clarify this? Correct. If the server doesn't support 3046, then it cannot possibly support 3527. ------_=_NextPart_001_01C48573.2FCB91A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] questions on RFC 3046 and RFC 3527

> Hello all,
>
> I have some questions regarding RFC3046 and = RFC3527:
>
> Q1.
>
> RFC3046 defines the Relay Agent Information = Option. One of
> the sub option
> for this option is Agent Remote ID Sub-option. = A possible
> value for this
> sub-option can be "the remote IP address = of a point-to-point link".

Note the phrasing that a _possible_ value for this = sub-option....
 
> RFC3527 defines another sub-option for Relay = Agent
> Information Option called
> Link selection sub-option. The possible value = for this
> sub-option can be the
> subnet (of the link) of the DHCP client.
>
> The question is, why the IP address in = "Agent Remote ID
> Sub-option" can't be
> used to identify the subnet of link for the = DHCP client? Why
> there was a
> need for two separate sub-options to convey the = same thing?

Because the RemoteID isn't necessarily an IP = address?

At least one well-known standard (DOCSIS) sepcifies = that the Remote ID is the MAC address of the cable modem, and not an IP = address.

> Q2.
>
> RFC3046 says:
>
> "
> 2.2 Server Operation
>
>    DHCP servers unaware of the = Relay Agent Information option will
>    ignore the option upon = receive and will not echo it back on
>    responses.  This is the = specified server behavior for unknown
>    options.
> "
> RFC3527 says:
>
> "
>    When the DHCP server is = allocating an address and this
> sub-option is
>    present, then the DHCP server = MUST allocate the address on either:
>
>       o  the = subnet specified in the link-selection sub-option, or;
>
>       o  a = subnet on the same link (also known as a network
> segment) as
>          the = subnet specified by the link-selection sub-option.
> "
>
> The confusion is: RFC3527 seems to mandate the = DHCP server to
> assign IP
> address based on link-selection sub-option when = this
> sub-option is present
> in the received request, but RFC3046 says that = the entire Relay Agent
> Information option can be ignored by the DHCP = server if it is
> not supported.
> Could someone clarify this?

Correct.  If the server doesn't support 3046, = then it cannot possibly support 3527.

------_=_NextPart_001_01C48573.2FCB91A0-- --===============1903579874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1903579874==-- From dhcwg-bounces@ietf.org Wed Aug 18 19:21:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29626; Wed, 18 Aug 2004 19:21:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZfa-00027b-6I; Wed, 18 Aug 2004 19:16:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZdH-0001c2-8h for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 19:14:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29376 for ; Wed, 18 Aug 2004 19:14:12 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxZja-0005F8-ET for dhcwg@ietf.org; Wed, 18 Aug 2004 19:20:46 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7IND2v16021; Wed, 18 Aug 2004 19:13:02 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 19:13:03 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92025D7742@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Wed, 18 Aug 2004 19:12:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks for your response. > Because the RemoteID isn't necessarily an IP address? > At least one well-known standard (DOCSIS) sepcifies that the Remote ID is the MAC address of the cable > modem, and not an IP address. It is true that RemoteID is not necessarily an IP address, but it MAY be an IP address. The question is, if the RemoteID is an IP address, is the use of RFC 3527 redundant or there are some other reason to include the Link selection sub-option? Regarding the confusion between RFC 3046 and RFC 3527 (Q2), I think RFC 3527 should say: "If the DHCP server supports the Relay Agent Information Option the DHCP server MUST allocate the address based on the following when the received Relay Agent Information Option contains the Link selection sub-option: " -Kuntal -----Original Message----- From: Kostur, Andre [mailto:akostur@incognito.com] Sent: Wednesday, August 18, 2004 5:32 PM To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; dhcwg@ietf.org Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 > Hello all, > > I have some questions regarding RFC3046 and RFC3527: > > Q1. > > RFC3046 defines the Relay Agent Information Option. One of > the sub option > for this option is Agent Remote ID Sub-option. A possible > value for this > sub-option can be "the remote IP address of a point-to-point link". Note the phrasing that a _possible_ value for this sub-option.... > RFC3527 defines another sub-option for Relay Agent > Information Option called > Link selection sub-option. The possible value for this > sub-option can be the > subnet (of the link) of the DHCP client. > > The question is, why the IP address in "Agent Remote ID > Sub-option" can't be > used to identify the subnet of link for the DHCP client? Why > there was a > need for two separate sub-options to convey the same thing? Because the RemoteID isn't necessarily an IP address? At least one well-known standard (DOCSIS) sepcifies that the Remote ID is the MAC address of the cable modem, and not an IP address. > Q2. > > RFC3046 says: > > " > 2.2 Server Operation > > DHCP servers unaware of the Relay Agent Information option will > ignore the option upon receive and will not echo it back on > responses. This is the specified server behavior for unknown > options. > " > RFC3527 says: > > " > When the DHCP server is allocating an address and this > sub-option is > present, then the DHCP server MUST allocate the address on either: > > o the subnet specified in the link-selection sub-option, or; > > o a subnet on the same link (also known as a network > segment) as > the subnet specified by the link-selection sub-option. > " > > The confusion is: RFC3527 seems to mandate the DHCP server to > assign IP > address based on link-selection sub-option when this > sub-option is present > in the received request, but RFC3046 says that the entire Relay Agent > Information option can be ignored by the DHCP server if it is > not supported. > Could someone clarify this? Correct. If the server doesn't support 3046, then it cannot possibly support 3527. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 18 19:43:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00687; Wed, 18 Aug 2004 19:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZyv-0001lO-JD; Wed, 18 Aug 2004 19:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZuo-00017c-8C for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 19:32:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00179 for ; Wed, 18 Aug 2004 19:32:19 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxa14-0005Wa-BM for dhcwg@ietf.org; Wed, 18 Aug 2004 19:38:53 -0400 Received: from homerdmz.incognito.com ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.30) id 1BxZuF-0002yG-Do; Wed, 18 Aug 2004 16:31:47 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 16:31:17 -0700 Message-ID: From: "Kostur, Andre" To: "'Kuntal Chowdhury'" , "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Wed, 18 Aug 2004 16:31:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "chimera.incognito.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. > Thanks for your response. > > > Because the RemoteID isn't necessarily an IP address? > > At least one well-known standard (DOCSIS) sepcifies that > the Remote ID is > the MAC address of the cable > > modem, and not an IP address. > > It is true that RemoteID is not necessarily an IP address, > but it MAY be an > IP address. The question is, if the RemoteID is an IP > address, is the use of > RFC 3527 redundant or there are some other reason to include the Link > selection sub-option? [...] Content analysis details: (2.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 HTML_MESSAGE BODY: HTML included in message 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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="===============0472775234==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0472775234== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4857B.74BE0BA0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4857B.74BE0BA0 Content-Type: text/plain; charset="iso-8859-1" > Thanks for your response. > > > Because the RemoteID isn't necessarily an IP address? > > At least one well-known standard (DOCSIS) sepcifies that > the Remote ID is > the MAC address of the cable > > modem, and not an IP address. > > It is true that RemoteID is not necessarily an IP address, > but it MAY be an > IP address. The question is, if the RemoteID is an IP > address, is the use of > RFC 3527 redundant or there are some other reason to include the Link > selection sub-option? However, the DHCP Service cannot assume that the RemoteID is an IP Address. All it knows is that there's this binary blob of data to be used for certain logic, that that the RemoteID is unique (See section 3.2 of 3046). And, how would the service distinguish between an IP address and any other 4 byte Remote ID? > Regarding the confusion between RFC 3046 and RFC 3527 (Q2), I > think RFC 3527 > should say: > > "If the DHCP server supports the Relay Agent Information > Option the DHCP > server MUST allocate the address based on the following when > the received > Relay Agent Information Option contains the Link selection sub-option: > " I don't understand the confusion. All 3527 says is that IF a DHCP server claims to implement 3527, then the server must perform the address allocation in the specified manner. And since 3527 cannot be implemented without implementing 3046, having 3046 support is implied. ------_=_NextPart_001_01C4857B.74BE0BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] questions on RFC 3046 and RFC 3527

> Thanks for your response.
>
> > Because the RemoteID isn't necessarily an = IP address?
> > At least one well-known standard (DOCSIS) = sepcifies that
> the Remote ID is
> the MAC address of the cable
> > modem, and not an IP address.
>
> It is true that RemoteID is not necessarily an = IP address,
> but it MAY be an
> IP address. The question is, if the RemoteID is = an IP
> address, is the use of
> RFC 3527 redundant or there are some other = reason to include the Link
> selection sub-option?

However, the DHCP Service cannot assume that the = RemoteID is an IP Address.  All it knows is that there's this = binary blob of data to be used for certain logic, that that the = RemoteID is unique (See section 3.2 of 3046).  And, how would the = service distinguish between an IP address and any other 4 byte Remote = ID?

 
> Regarding the confusion between RFC 3046 and = RFC 3527 (Q2), I
> think RFC 3527
> should say:
>
> "If the DHCP server supports the Relay = Agent Information
> Option the DHCP
> server MUST allocate the address based on the = following when
> the received
> Relay Agent Information Option contains the = Link selection sub-option:
> "

I don't understand the confusion.  All 3527 says = is that IF a DHCP server claims to implement 3527, then the server must = perform the address allocation in the specified manner.  And since = 3527 cannot be implemented without implementing 3046, having 3046 = support is implied.

------_=_NextPart_001_01C4857B.74BE0BA0-- --===============0472775234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0472775234==-- From dhcwg-bounces@ietf.org Wed Aug 18 19:54:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01453; Wed, 18 Aug 2004 19:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxa9y-0003l5-Rt; Wed, 18 Aug 2004 19:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxa86-0003Nf-Rl for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 19:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00859 for ; Wed, 18 Aug 2004 19:46:05 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxaEP-0005lc-EA for dhcwg@ietf.org; Wed, 18 Aug 2004 19:52:38 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 71F651B22E8; Wed, 18 Aug 2004 18:42:41 -0500 (CDT) In-Reply-To: <591B780D9676844E8A704B5B013FFE92025D7742@zrc2hxm1.corp.nortel.com> References: <591B780D9676844E8A704B5B013FFE92025D7742@zrc2hxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Wed, 18 Aug 2004 16:45:59 -0700 To: "Kuntal Chowdhury" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "Kostur, Andre" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 18, 2004, at 4:12 PM, Kuntal Chowdhury wrote: > It is true that RemoteID is not necessarily an IP address, but it MAY > be an > IP address. The question is, if the RemoteID is an IP address, is the > use of > RFC 3527 redundant or there are some other reason to include the Link > selection sub-option? The DHCP server will use the link selection suboption to select the link on which to configure the client. It will not use the remote ID option for this purpose. If you can't think of a reason to send the link selection suboption, do not send it. It is intended for a specific purpose, and is not something that every relay agent should send in all circumstances. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From AHVIKQG@msn.com Wed Aug 18 21:06:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04840; Wed, 18 Aug 2004 21:06:44 -0400 (EDT) Received: from pcp02659500pcs.1500mk01.pa.comcast.net ([68.84.114.9]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BxbUR-00079i-Nv; Wed, 18 Aug 2004 21:13:18 -0400 Received: from 0.198.208.48 by 68.84.114.9; Thu, 19 Aug 2004 07:01:39 +0500 Message-ID: From: "Erika Albert" Reply-To: "Erika Albert" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive T3 with codeine is here Date: Wed, 18 Aug 2004 23:06:39 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--16841576810673297" X-Priority: 1 X-IP: 52.125.144.160 X-Spam-Score: 12.4 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 ----16841576810673297 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable







not interested c-l-i-c-k here ----16841576810673297-- From admin@computeradmin.org Thu Aug 19 01:02:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16925; Thu, 19 Aug 2004 01:02:23 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxfAW-0002qw-VM; Thu, 19 Aug 2004 01:08:58 -0400 Received: from cpe-61-9-213-225.qld.bigpond.net.au ([61.9.213.225]) by mx2.foretec.com with smtp (Exim 4.24) id 1Bxf48-0004KS-3P; Thu, 19 Aug 2004 01:02:21 -0400 Received: from v9.ov32zqw.net ([47.181.243.251]) by CPE-61-9-213-225.qld.bigpond.net.au with ESMTP id 60452060; Thu, 19 Aug 2004 08:04:00 +0200 Message-ID: From: "Administrator" To: dhcipv6-archive@ietf.org Subject: Staff Bulletin Date: Thu, 19 Aug 04 08:04:00 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="__F470D2E7..A_.C_16" X-Spam-Score: 23.9 (+++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --__F470D2E7..A_.C_16 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Staff Members: You Must Respond By 5 P.M. Friday, August 20, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Staff Members who respond to this message before 5 P.M., Friday, August 20, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, August 20, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Nonprofit or School Staff Member. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, August 20, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, August 20, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --__F470D2E7..A_.C_16-- From dhcwg-bounces@ietf.org Thu Aug 19 16:54:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08271; Thu, 19 Aug 2004 16:54:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxsey-0002OT-Ck; Thu, 19 Aug 2004 15:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxsal-0000R9-5c for dhcwg@megatron.ietf.org; Thu, 19 Aug 2004 15:28:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27660 for ; Thu, 19 Aug 2004 15:28:53 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxshE-0002x4-7F for dhcwg@ietf.org; Thu, 19 Aug 2004 15:35:37 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7JJRkd29376; Thu, 19 Aug 2004 15:27:46 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Aug 2004 15:27:44 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE920262DE0C@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Ted Lemon , "Kostur, Andre" Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Thu, 19 Aug 2004 15:27:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ted/Kostur, Thanks for the clarification. Now I understand the use of these sub-options better. -Kuntal >-----Original Message----- >From: Ted Lemon [mailto:mellon@nominum.com] >Sent: Wednesday, August 18, 2004 6:46 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: dhcwg@ietf.org; Kostur, Andre >Subject: Re: [dhcwg] questions on RFC 3046 and RFC 3527 > > >On Aug 18, 2004, at 4:12 PM, Kuntal Chowdhury wrote: >> It is true that RemoteID is not necessarily an IP address, but it MAY >> be an >> IP address. The question is, if the RemoteID is an IP >address, is the >> use of >> RFC 3527 redundant or there are some other reason to include the Link >> selection sub-option? > >The DHCP server will use the link selection suboption to select the >link on which to configure the client. It will not use the remote ID >option for this purpose. If you can't think of a reason to send the >link selection suboption, do not send it. It is intended for a >specific purpose, and is not something that every relay agent should >send in all circumstances. > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 07:42:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06219; Fri, 20 Aug 2004 07:42:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7Wl-0007lw-PG; Fri, 20 Aug 2004 07:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7Dr-0003dC-Aq for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 07:06:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04659 for ; Fri, 20 Aug 2004 07:06:07 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By7KN-0004mw-QB for dhcwg@ietf.org; Fri, 20 Aug 2004 07:13:01 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KB5a2M008925; Fri, 20 Aug 2004 13:05:36 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KB5ZsK014847; Fri, 20 Aug 2004 13:05:35 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 13:05:35 +0200 From: Stig Venaas To: Dave Thaler Subject: Re: [dhcwg] RE: mboned:draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Message-ID: <20040820110535.GB14315@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 13, 2004 at 04:54:02PM -0700, Dave Thaler wrote: > Stig Venaas writes: > > If we instead used the stateless prefix announcement solution we may > > need to solve the DAD issue, but there are some advantages. > > > > o For link-local multicast, it would be possible to generate link > > unique multicast addresses with no need for DHCP servers or routers. > > Right. This is what > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-04 > .txt > does. Yes, so we have a good solution for that already I think. > > o For unicast-prefix-based addressing (RFC 3306) you can generate a > > /96 multicast prefix from the links unicast /64 prefix and then > > using RNG plus possibly DAD you can come up with prefixes to use on > > the link. This can be done without DHCP. > > Right. > > > o For Embedded-RP the application will need to learn the prefix from > > somewhere. But the system could learn the prefix once (from DHCP, > > from config file or whatever) and all the applications use the same. > > You can perhaps compare it to how applications use resolv.conf on > > unix and how it might be configured from DHCP or other systems. > > And you need a DAD mechanism for address selection within the prefix, > as with 3306 addresses. Yes. I'm not sure it's a good idea, but have you considered whether LLMNR could be used for multicast DAD? I think it could be done easily, but it's perhaps a bit ugly since since it uses LLMNR for something it isn't designed for perhaps. Another option could be to use or copy the unicast ND DAD mechanism. I'm sure it would work. You could possibly use ND DAD as it is, with some standardized way of mapping group addresses to interface id's. That feels wrong to me, but you could copy the mechanism, and perhaps add new "multicast group solicit" and "multicast group advertise" messages that work exactly like todays unicast solicit and advertise. Well, just some ideas, not sure how good they are... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 08:28:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09096; Fri, 20 Aug 2004 08:28:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By86R-00075g-7d; Fri, 20 Aug 2004 08:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7s8-0004D8-Tc for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 07:47:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06669 for ; Fri, 20 Aug 2004 07:47:46 -0400 (EDT) Received: from mail.loqal.no ([82.194.192.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By7yf-0005QW-QY for dhcwg@ietf.org; Fri, 20 Aug 2004 07:54:39 -0400 Received: from bbsrv1.loqal.no (bbsrv1.loqal.no [127.0.0.1]) by mail.loqal.no (Postfix) with ESMTP id A1A674BDC7 for ; Fri, 20 Aug 2004 13:46:38 +0200 (CEST) Received: from mail.loqal.no (bbsrv1.loqal.no [127.0.0.1]) by bbsrv1.loqal.no (VaMailArmor-2.0.1.16) id 18865-1691D8EF; Fri, 20 Aug 2004 13:46:38 +0200 Received: from terje (unknown [82.194.195.52]) by mail.loqal.no (Postfix) with ESMTP id 88B364BDC7 for ; Fri, 20 Aug 2004 13:46:22 +0200 (CEST) To: dhcwg@ietf.org Date: Fri, 20 Aug 2004 13:46:23 +0200 From: "Terje Andersen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/7.54 (Win32, build 3869) X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.22; host: bbsrv1.loqal.no) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit Subject: [dhcwg] DHCP in my local area network. 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 8bit First of all, my english is not to well :) Hi. I am the manager of a computer club called Meldal-LAN. Because of issues with the broadband company, we cant get IP's from them anymore. We therefor plan to set up a server, with 2,6Ghz Prescott CPU and 1GB Corsair Dual Ram. The network solution will be a 10/100 pci who recieves the internet, and 2X10/100/1000 linked together that shares IP's. The server will primarly be running as a DHCP, but also to host games, host movie vision and share files. We plan to run Windows 2000 on the server. 1: Do you think the hardware aspects is good enough? 2: The computer club has about 50 members, do the DHCP get problems sharing out so many IP's? 3: Is there hard to configure the DHCP so that people can play online and stuff? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 08:29:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09141; Fri, 20 Aug 2004 08:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By86S-00075s-3I; Fri, 20 Aug 2004 08:02:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7sn-0004Ew-VN for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 07:48:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06709 for ; Fri, 20 Aug 2004 07:48:27 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By7zI-0005TE-LT for dhcwg@ietf.org; Fri, 20 Aug 2004 07:55:20 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KBlT2M020509; Fri, 20 Aug 2004 13:47:30 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KBlSPO014932; Fri, 20 Aug 2004 13:47:28 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 13:47:28 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040820114728.GC14315@sverresborg.uninett.no> References: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> <200408121018.57077.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com, Bernie Volz 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 17, 2004 at 05:45:05PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Thu, 12 Aug 2004 10:18:57 -0400, > >>>>> Joe Quanaim said: > > >> The primary motivation for the lifetime option is for situations where > >> no lifetime (or renewal time) is communicated to the client, such as for > >> Stateless DHCP service as specified in [RFC 3736]. However, it applies > >> to both stateful and stateless DHCP clients and is an upper bound for > >> when a client should initiate renewal of at least its non-address based > >> configuration parameters - a stateful client MAY renew its addresses at > >> the same time and SHOULD always get updated configuration data from the > >> server when it renews any addresses. > >> > >> One difference between Stateful and Stateless clients with regards > >> to this option is that a Stateful client that does not receive this > >> option MUST NOT apply the default lifetime. > > > As noted, the motivation of the lifetime option is to ensure stateless clients > > receive current configuration information. As such, I think keeping it out > > of stateful configuration is the simplest approach. As we have discussed, > > stateful configuration already has several variables to manipulate client > > behavior. I do not see much gain in adding another. > > It's not a strong opinion, but I'd also still prefer to restrict the > use of the lifetime option to the stateless case. The reasons are: I think we should come to a decision and proceed. I've given this some more thought, and personally I don't mind restricting it to stateless. I'm not sure I like using the term stateless though. I suggest saying that the option should only be used in replies to Information-Request messages. This solves the stateless renumbering issue we set out to solve. > - even if it might be true that the client can use stateful exchanges > without having addresses or infinite T1/T2 timers for other > configurations only, it should be a very minor case (I'm pretty sure > that everyone agrees on this - whether still want to allow such > usage or not). In my understanding, the sense of RFC3315 is that > "if you can get an address, you may get other information. If you > cannot get an address, then give up any possible information." In > fact, Section 18.1.8 says > > [...] If the client receives no addresses in > any of the IAs, it may either try another server (perhaps restarting > the DHCP server discovery process) or use the Information-request > message to obtain other configuration information only. > > but the RFC does not (explicitly) allow the client to continue to > use other information configuration than addresses. What you are > going to achieve in the scenario of the lifetime option with the > stateful case seems to contradict the original sense, IMO. > > - recalling that we rejected the idea of multiple lifetime options for > multiple configuration parameters, it's odd to me that we are now > going to have T1/T2 as well as the lifetime option (I was happy with > rejecting the idea of multiple lifetimes, BTW). If we applied the > same logic, we could simply use an appropriate T1 value to implement > controlled update of the other configuration information. Again, > it's true that stateful exchanges can provide no finite timers, > but, as I said in the above bullet, it's very minor or even > almost-unexpected use case in my understanding. I agree with this. At least it's my understanding that when renewing the address the client should also update other info. > - as I pointed out in my first message, we'll have to define all the > details, most of which are boring corner cases (but the implementors > would be unhappy if we didn't define those). I know some of you are > now trying to address those, and trying to minimize the complexity > of the specification. However, right now I'm not sure if it really > makes sense, considering the usage case of stateful+lifetime is > minor. I admit this is a tradeoff issue, and perhaps we need to > end up discussing details to make a clear consensus. Yes, it might be just corner cases. I guess the scope of the option could be expanded later if needed. It's better to do that later, than possibly making the scope too large now. > - one thing I'm concerned about which is related to the above point: > there is already a non-address IA that has a notion of timeout: > IA_PD. So, we'll probably have to consider the combination of IA_PD > and the lifetime option. Moreover, the lifetime option document may > need to be generic enough to prepare for any future stateful > resources that has a notion of timeout. Right. > > Still, it's not that complex a change. If I am outvoted, so be it. > > Same here. Though I'm still skeptical about the benefit of the use > case of stateful+lifetime, considering the possible complexity, I can > live with that if the specification is crystal clear about all the > details. I must say I don't quite understand why it is so difficult. OTOH it seems I have some problems explaining clearly how I think it should work, so perhaps it is complex after all (; Well, are you happy with limiting it to replies to Information-Request then? Has anyone got big problems with that? If there are no major objections I'll propose some text to you, to make sure we are in agreement. Thanks for all the input. I hope to go through the issues, proposing text and hopefully have concencus on how to resolve it so that I can put out a new and hopefully final version soon. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 09:17:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11616; Fri, 20 Aug 2004 09:17:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By8tl-0007lH-AD; Fri, 20 Aug 2004 08:53:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By8lQ-00054y-Ln for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 08:45:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09941 for ; Fri, 20 Aug 2004 08:44:53 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By8rv-0006cR-S9 for dhcwg@ietf.org; Fri, 20 Aug 2004 08:51:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Aug 2004 05:48:51 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7KCiGIU000114; Fri, 20 Aug 2004 05:44:17 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-84.cisco.com [10.86.240.84]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKZ29103; Fri, 20 Aug 2004 08:44:15 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" , "'JINMEI Tatuya / ?$B?@L@C#:H'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Fri, 20 Aug 2004 08:44:14 -0400 Organization: Cisco Message-ID: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040820114728.GC14315@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'm OK to restricting the Lifetime Option to replies to Information-Request's. The client MUST ignore a Lifetime Option that is in any message other = than a REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime Option number in an ORO except when sending an INFORMATION-REQUEST = message. The server MUST NOT include the Lifetime Option in any message other = than a REPLY to an INFORMATION-REQUEST. - Bernie > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > Sent: Friday, August 20, 2004 7:47 AM > To: JINMEI Tatuya / ?$B?@L@C#:H > Cc: jdq@lucent.com; dhcwg@ietf.org; tjc@ecs.soton.ac.uk; Bernie Volz > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > On Tue, Aug 17, 2004 at 05:45:05PM +0900, JINMEI Tatuya /=20 > ?$B?@L@C#:H wrote: > > >>>>> On Thu, 12 Aug 2004 10:18:57 -0400, > > >>>>> Joe Quanaim said: > >=20 > > >> The primary motivation for the lifetime option is for situations=20 > > >> where no lifetime (or renewal time) is communicated to=20 > the client,=20 > > >> such as for Stateless DHCP service as specified in [RFC 3736].=20 > > >> However, it applies to both stateful and stateless DHCP=20 > clients and=20 > > >> is an upper bound for when a client should initiate=20 > renewal of at=20 > > >> least its non-address based configuration parameters - a=20 > stateful=20 > > >> client MAY renew its addresses at the same time and=20 > SHOULD always=20 > > >> get updated configuration data from the server when it=20 > renews any=20 > > >> addresses. > > >>=20 > > >> One difference between Stateful and Stateless clients=20 > with regards=20 > > >> to this option is that a Stateful client that does not=20 > receive this=20 > > >> option MUST NOT apply the default lifetime. > >=20 > > > As noted, the motivation of the lifetime option is to ensure=20 > > > stateless clients > > > receive current configuration information. As such, I=20 > think keeping it out=20 > > > of stateful configuration is the simplest approach. As=20 > we have discussed,=20 > > > stateful configuration already has several variables to=20 > manipulate client=20 > > > behavior. I do not see much gain in adding another. > >=20 > > It's not a strong opinion, but I'd also still prefer to=20 > restrict the=20 > > use of the lifetime option to the stateless case. The reasons are: >=20 > I think we should come to a decision and proceed. I've given=20 > this some more thought, and personally I don't mind=20 > restricting it to stateless. I'm not sure I like using the=20 > term stateless though. >=20 > I suggest saying that the option should only be used in=20 > replies to Information-Request messages. This solves the=20 > stateless renumbering issue we set out to solve. >=20 > > - even if it might be true that the client can use stateful=20 > exchanges > > without having addresses or infinite T1/T2 timers for other > > configurations only, it should be a very minor case (I'm=20 > pretty sure > > that everyone agrees on this - whether still want to allow such > > usage or not). In my understanding, the sense of RFC3315 is that > > "if you can get an address, you may get other information. If you > > cannot get an address, then give up any possible information." In > > fact, Section 18.1.8 says > >=20 > > [...] If the client receives no addresses in > > any of the IAs, it may either try another server=20 > (perhaps restarting > > the DHCP server discovery process) or use the=20 > Information-request > > message to obtain other configuration information only. > >=20 > > but the RFC does not (explicitly) allow the client to continue to > > use other information configuration than addresses. What you are > > going to achieve in the scenario of the lifetime option with the > > stateful case seems to contradict the original sense, IMO. > >=20 > > - recalling that we rejected the idea of multiple lifetime=20 > options for > > multiple configuration parameters, it's odd to me that we are now > > going to have T1/T2 as well as the lifetime option (I was=20 > happy with > > rejecting the idea of multiple lifetimes, BTW). If we applied the > > same logic, we could simply use an appropriate T1 value=20 > to implement > > controlled update of the other configuration information. Again, > > it's true that stateful exchanges can provide no finite timers, > > but, as I said in the above bullet, it's very minor or even > > almost-unexpected use case in my understanding. >=20 > I agree with this. At least it's my understanding that when=20 > renewing the address the client should also update other info. >=20 > > - as I pointed out in my first message, we'll have to define all the > > details, most of which are boring corner cases (but the=20 > implementors > > would be unhappy if we didn't define those). I know some=20 > of you are > > now trying to address those, and trying to minimize the complexity > > of the specification. However, right now I'm not sure if=20 > it really > > makes sense, considering the usage case of stateful+lifetime is > > minor. I admit this is a tradeoff issue, and perhaps we need to > > end up discussing details to make a clear consensus. >=20 > Yes, it might be just corner cases. I guess the scope of the=20 > option could be expanded later if needed. It's better to do=20 > that later, than possibly making the scope too large now. >=20 > > - one thing I'm concerned about which is related to the above point: > > there is already a non-address IA that has a notion of timeout: > > IA_PD. So, we'll probably have to consider the=20 > combination of IA_PD > > and the lifetime option. Moreover, the lifetime option=20 > document may > > need to be generic enough to prepare for any future stateful > > resources that has a notion of timeout. >=20 > Right. >=20 > > > Still, it's not that complex a change. If I am outvoted,=20 > so be it. > >=20 > > Same here. Though I'm still skeptical about the benefit of the use=20 > > case of stateful+lifetime, considering the possible=20 > complexity, I can=20 > > live with that if the specification is crystal clear about all the=20 > > details. >=20 > I must say I don't quite understand why it is so difficult.=20 > OTOH it seems I have some problems explaining clearly how I=20 > think it should work, so perhaps it is complex after all (; >=20 > Well, are you happy with limiting it to replies to=20 > Information-Request then? Has anyone got big problems with=20 > that? If there are no major objections I'll propose some text=20 > to you, to make sure we are in agreement. >=20 > Thanks for all the input. I hope to go through the issues,=20 > proposing text and hopefully have concencus on how to resolve=20 > it so that I can put out a new and hopefully final version soon. >=20 > Stig >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 10:07:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14457; Fri, 20 Aug 2004 10:07:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9eB-0007su-FG; Fri, 20 Aug 2004 09:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9QQ-0005Ga-Cg for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 09:27:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12113 for ; Fri, 20 Aug 2004 09:27:15 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By9Wy-0007MB-2O for dhcwg@ietf.org; Fri, 20 Aug 2004 09:34:09 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KDOs2M012985; Fri, 20 Aug 2004 15:24:54 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KDOpV0015082; Fri, 20 Aug 2004 15:24:51 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 15:24:51 +0200 From: Stig Venaas To: Bernie Volz Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040820132451.GD14315@sverresborg.uninett.no> References: <20040820114728.GC14315@sverresborg.uninett.no> <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 20, 2004 at 08:44:14AM -0400, Bernie Volz wrote: > I'm OK to restricting the Lifetime Option to replies to > Information-Request's. > > The client MUST ignore a Lifetime Option that is in any message other than a > REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > Option number in an ORO except when sending an INFORMATION-REQUEST message. > > The server MUST NOT include the Lifetime Option in any message other than a > REPLY to an INFORMATION-REQUEST. Right, sounds good. Thanks for the text. This brings up another thing I want to discuss. Is it actually useful for the client to include it in ORO at all? Should the server really care? I can think of basically three options. I'll be a bit vague on the MAY/SHOULD/MUSTs for now. 1. Client may include it. If server sees option it should include it in reply. If server does not see it, it may include it anyway. 2. Client always includes it, and server only includes it in reply if client included it in request. 3. Client never includes it, and server always or never includes it depending on configuration. It would be nice to come to agreement on which alternative is best before trying to formalize things. Personally I think alternative 3 makes sense. That is, if a server implements the option and is configured with some lifetime by the administrator, then it should always include it. If it is not configured by the administrator, then it should not include it, so that clients will just use the default. Or do you see a problem with server including the option when client doesn't implement it? Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 10:47:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17795; Fri, 20 Aug 2004 10:47:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByA9W-0001Vs-Rc; Fri, 20 Aug 2004 10:13:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9qS-00027k-EB for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 09:54:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13423 for ; Fri, 20 Aug 2004 09:54:09 -0400 (EDT) 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.33) id 1By9wy-0007pR-Cz for dhcwg@ietf.org; Fri, 20 Aug 2004 10:01:03 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2004 06:59:14 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7KDrWH6010368; Fri, 20 Aug 2004 06:53:33 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-84.cisco.com [10.86.240.84]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKZ33480; Fri, 20 Aug 2004 09:53:31 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Fri, 20 Aug 2004 09:53:31 -0400 Organization: Cisco Message-ID: <001d01c486bd$13f1c850$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040820132451.GD14315@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable YES! The client MUST include this in the ORO if it is interested in the parameter. Ted discussed this on the mailing list a few weeks back - = that options really must be in the ORO. And, I do agree with him that this is = the best policy. If I recall correctly, Ted stated that if a client "wants" an option, it MUST include it in the ORO. A server MUST return any options for which it has information if they = are in the ORO. A server MAY include other options that are not in the ORO BUT there is NO requirement that it must do so. Note that there are a few exceptions, such as Client-ID, Server-ID, = IA_NA, IA_TA, IAADDR, ... as these are protocol options. So, by this rule, the client MUST include it in the ORO to assure it = gets it if configured and supported by the server. - Bernie > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > Sent: Friday, August 20, 2004 9:25 AM > To: Bernie Volz > Cc: 'JINMEI Tatuya / ?$B?@L@C#:H'; jdq@lucent.com;=20 > dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > On Fri, Aug 20, 2004 at 08:44:14AM -0400, Bernie Volz wrote: > > I'm OK to restricting the Lifetime Option to replies to=20 > > Information-Request's. > >=20 > > The client MUST ignore a Lifetime Option that is in any=20 > message other=20 > > than a REPLY to an INFORMATION-REQUEST. A client MUST NOT=20 > include the=20 > > Lifetime Option number in an ORO except when sending an=20 > > INFORMATION-REQUEST message. > >=20 > > The server MUST NOT include the Lifetime Option in any=20 > message other=20 > > than a REPLY to an INFORMATION-REQUEST. >=20 > Right, sounds good. Thanks for the text. >=20 > This brings up another thing I want to discuss. >=20 > Is it actually useful for the client to include it in ORO at=20 > all? Should the server really care? >=20 > I can think of basically three options. I'll be a bit vague=20 > on the MAY/SHOULD/MUSTs for now. >=20 > 1. Client may include it. If server sees option it should include > it in reply. If server does not see it, it may include it anyway. >=20 > 2. Client always includes it, and server only includes it in reply if > client included it in request. >=20 > 3. Client never includes it, and server always or never includes it > depending on configuration. >=20 > It would be nice to come to agreement on which alternative is=20 > best before trying to formalize things. >=20 >=20 > Personally I think alternative 3 makes sense. >=20 > That is, if a server implements the option and is configured=20 > with some lifetime by the administrator, then it should=20 > always include it. >=20 > If it is not configured by the administrator, then it should=20 > not include it, so that clients will just use the default. >=20 > Or do you see a problem with server including the option when=20 > client doesn't implement it? >=20 > Stig >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 11:05:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19173; Fri, 20 Aug 2004 11:05:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAde-00013k-Ef; Fri, 20 Aug 2004 10:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByA8Y-0001DF-Dh for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 10:12:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15105 for ; Fri, 20 Aug 2004 10:12:51 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByAF4-0008Bo-GI for dhcwg@ietf.org; Fri, 20 Aug 2004 10:19:45 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KEB32M024323; Fri, 20 Aug 2004 16:11:03 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KEB29h015172; Fri, 20 Aug 2004 16:11:02 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 16:11:02 +0200 From: Stig Venaas To: Bernie Volz Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040820141102.GE14315@sverresborg.uninett.no> References: <20040820132451.GD14315@sverresborg.uninett.no> <001d01c486bd$13f1c850$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001d01c486bd$13f1c850$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 20, 2004 at 09:53:31AM -0400, Bernie Volz wrote: > YES! The client MUST include this in the ORO if it is interested in the > parameter. Ted discussed this on the mailing list a few weeks back - that > options really must be in the ORO. And, I do agree with him that this is the > best policy. > > If I recall correctly, Ted stated that if a client "wants" an option, it > MUST include it in the ORO. I apologize for my ignorance, I don't know DHCP well enough. I found and read Ted's mail now. I see how it simplifies server implementation. I think I have enough input to propose new text for the draft now. I'll post a proposal soon. Thanks for your input and patience, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 11:38:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21897; Fri, 20 Aug 2004 11:38:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByB2z-0008TY-F7; Fri, 20 Aug 2004 11:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAov-0003lZ-AB for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 10:56:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18319 for ; Fri, 20 Aug 2004 10:56:37 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByAvT-0000b7-S9 for dhcwg@ietf.org; Fri, 20 Aug 2004 11:03:33 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7KEtVAS013197; Fri, 20 Aug 2004 09:55:31 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7KEtUo15967; Fri, 20 Aug 2004 10:55:30 -0400 (EDT) From: Joe Quanaim To: "Bernie Volz" , "'Stig Venaas'" , "'JINMEI Tatuya / ?$B?@L@C#:H'" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Fri, 20 Aug 2004 10:55:04 -0400 User-Agent: KMail/1.5.4 References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> In-Reply-To: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408201053.49786.jdq@lucent.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie Volz wrote: > I'm OK to restricting the Lifetime Option to replies to > Information-Request's. > > The client MUST ignore a Lifetime Option that is in any message other than > a REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > Option number in an ORO except when sending an INFORMATION-REQUEST message. > > The server MUST NOT include the Lifetime Option in any message other than a > REPLY to an INFORMATION-REQUEST. This sounds good to me. Also, did we reach consensus on a default value? This seems like the appropriate place to mention it: If a client requests a Lifetime Option and does not receive one in the reply, it should use the default value of n hours. Or something to that effect... Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 12:48:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26554; Fri, 20 Aug 2004 12:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByBVo-0006qi-7d; Fri, 20 Aug 2004 11:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByB4o-0000nv-HN for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 11:13:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19848 for ; Fri, 20 Aug 2004 11:13:02 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByBBL-000135-1F for dhcwg@ietf.org; Fri, 20 Aug 2004 11:19:58 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KF8G2M005146; Fri, 20 Aug 2004 17:08:16 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KF8F1q015281; Fri, 20 Aug 2004 17:08:15 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 17:08:15 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040820150815.GG14315@sverresborg.uninett.no> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <200408201053.49786.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408201053.49786.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 20, 2004 at 10:55:04AM -0400, Joe Quanaim wrote: > Bernie Volz wrote: > > I'm OK to restricting the Lifetime Option to replies to > > Information-Request's. > > > > The client MUST ignore a Lifetime Option that is in any message other than > > a REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > > Option number in an ORO except when sending an INFORMATION-REQUEST message. > > > > The server MUST NOT include the Lifetime Option in any message other than a > > REPLY to an INFORMATION-REQUEST. > > This sounds good to me. > > Also, did we reach consensus on a default value? This seems like the > appropriate place to mention it: > > If a client requests a Lifetime Option and does not receive one in the reply, > it should use the default value of n hours. > > Or something to that effect... Yes, I've already written some text to that effect, it's not done. What I have so far is: In some cases a default lifetime LT_DEFAULT is used. The recommended value for LT_DEFAULT is 21600 (6 hours). I just took 6 out of the air, input needed. and then under client behaviour: A client implementing this option MUST when a reply to an Information-Request message does not contain the option, behave as if the option with value LT_DEFAULT was provided. A client MUST also use the default lifetime LT_DEFAULT if the value of the option is zero. If client has received a lifetime with this option, and contacts server to receive new or update any existing data prior to its expiration, it SHOULD also update data covered by this option. If no new lifetime is received, it MUST use the default lifetime LT_DEFAULT. I need to work a bit more on the text, but let me know if this is not in line with what you think. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 14:49:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05350; Fri, 20 Aug 2004 14:49:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByDwz-0003wa-GN; Fri, 20 Aug 2004 14:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByCW1-0001fK-U7 for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 12:45:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25915 for ; Fri, 20 Aug 2004 12:45:14 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByCcd-00030K-5J for dhcwg@ietf.org; Fri, 20 Aug 2004 12:52:11 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Aug 2004 12:55:07 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7KGieY3009494; Fri, 20 Aug 2004 12:44:41 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-1-84.cisco.com [10.86.240.84]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKZ47834; Fri, 20 Aug 2004 12:44:38 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" , "'Joe Quanaim'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Fri, 20 Aug 2004 12:44:38 -0400 Organization: Cisco Message-ID: <002e01c486d4$fd93d810$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040820150815.GG14315@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable While the load on a server for processing Information-Requests should be relatively small, why use a default that is so short? This means that in = a typical working day (8 or more hours) while you've connected your laptop = at work, it will get the parameters when you first connect and at LEAST = once more. If we're to believe there will be billions of IPv6 devices and a = sizeable fraction will use stateless, why have all of this DHCP traffic? The lifetime mechanism MUST NOT be used in place of redundancy - if = you're only going to have one DNS resolving server, you're asking for trouble = and using this lifetime option to work aroud failures is NOT correct. This information should generally be valid for LONG time periods unless = a site has an explicit need to refresh this information more frequently, = in which case the server should be configured with the desired value. Personally I would like to see a DEFAULT lifetime of NOT LESS than 12 = hours. (Most operational network use a day to a week for lease times from my expierence.) Ask yourself what are typical LEASE times and cut these in half. Or, if = you have data on typical address LIFETIMES for IPv6 addresses, use these = values. And, remember we're specifying the DEFAULT. If a server administrator = wants to reduce this, she is free to do so. I also believe we should, in order to prevent Denial-of-Service attacks = or "Information-Request" storms, specify a LOWER BOUND of something like 10 minutes. And, the lifetime option shouldn't be the only trigger a client uses to refresh this information. Connecting a network cable to the client, significant changes in the prefixes active on the link, etc. are all = other considerations that a client SHOULD use to trigger refreshing this information. The lifetime should only apply to very STATIC situations - where the client isn't mobile and the network addresses don't change. - Bernie > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > Sent: Friday, August 20, 2004 11:08 AM > To: Joe Quanaim > Cc: Bernie Volz; 'JINMEI Tatuya / ?$B?@L@C#:H';=20 > dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > On Fri, Aug 20, 2004 at 10:55:04AM -0400, Joe Quanaim wrote: > > Bernie Volz wrote: > > > I'm OK to restricting the Lifetime Option to replies to=20 > > > Information-Request's. > > > > > > The client MUST ignore a Lifetime Option that is in any message=20 > > > other than a REPLY to an INFORMATION-REQUEST. A client MUST NOT=20 > > > include the Lifetime Option number in an ORO except when=20 > sending an=20 > > > INFORMATION-REQUEST message. > > > > > > The server MUST NOT include the Lifetime Option in any=20 > message other=20 > > > than a REPLY to an INFORMATION-REQUEST. > >=20 > > This sounds good to me. > >=20 > > Also, did we reach consensus on a default value? This=20 > seems like the > > appropriate place to mention it: > >=20 > > If a client requests a Lifetime Option and does not receive=20 > one in the=20 > > reply, > > it should use the default value of n hours. > >=20 > > Or something to that effect... >=20 > Yes, I've already written some text to that effect, it's not=20 > done. What I have so far is: >=20 > In some cases a default lifetime LT_DEFAULT is used. > The recommended value for LT_DEFAULT is 21600 (6 hours). >=20 > I just took 6 out of the air, input needed. >=20 > and then under client behaviour: >=20 > A client implementing this option MUST when a reply to an > Information-Request message does not contain the option, behave > as if the option with value LT_DEFAULT was provided. >=20 > A client MUST also use the default lifetime LT_DEFAULT if the > value of the option is zero. >=20 > If client has received a lifetime with this option, and contacts > server to receive new or update any existing data prior to its > expiration, it SHOULD also update data covered by this option. > If no new lifetime is received, it MUST use the default lifetime > LT_DEFAULT. >=20 > I need to work a bit more on the text, but let me know if=20 > this is not in line with what you think. >=20 > Stig >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 22 20:57:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29607; Sun, 22 Aug 2004 20:57:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz2qY-0007Sy-Jx; Sun, 22 Aug 2004 20:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz2en-0006XZ-6P for dhcwg@megatron.ietf.org; Sun, 22 Aug 2004 20:25:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28440 for ; Sun, 22 Aug 2004 20:25:46 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz2et-0007uI-S8 for dhcwg@ietf.org; Sun, 22 Aug 2004 20:26:01 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7N0OpG27539; Sun, 22 Aug 2004 20:24:52 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 22 Aug 2004 20:24:52 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92026F3BFD@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: dhcwg@ietf.org Date: Sun, 22 Aug 2004 20:24:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pyegani@cisco.com, Ralph Droms , ac@qualcomm.com, "Lila Madour \(QA/EMC\)" Subject: [dhcwg] (no subject) 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi all, -01 version of the BCMCS DHC options are now available: http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-bcmcv6-option-01.txt http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-bcmcv4-option-01.txt We have simplified the figure, removed FQDN compression requirement for v6 option, fixed the FQDN example in both the drafts. Thanks to Ralph Dorms, Ted Lemon and Bernie Volz for their review and comments. Regards, Kuntal _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 04:24:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20326; Mon, 23 Aug 2004 04:24:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz9pq-0003L6-Hr; Mon, 23 Aug 2004 04:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz9cq-0001hh-UV for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 03:52:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18771 for ; Mon, 23 Aug 2004 03:52:14 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz9d1-0006wr-Jn for dhcwg@ietf.org; Mon, 23 Aug 2004 03:52:32 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:d496:d9ca:8037:c688]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9A71A1525D; Mon, 23 Aug 2004 16:52:11 +0900 (JST) Date: Mon, 23 Aug 2004 16:52:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> References: <20040820114728.GC14315@sverresborg.uninett.no> <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, "'Stig Venaas'" , jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Fri, 20 Aug 2004 08:44:14 -0400, >>>>> "Bernie Volz" said: > I'm OK to restricting the Lifetime Option to replies to > Information-Request's. > The client MUST ignore a Lifetime Option that is in any message other than a > REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > Option number in an ORO except when sending an INFORMATION-REQUEST message. > The server MUST NOT include the Lifetime Option in any message other than a > REPLY to an INFORMATION-REQUEST. I'm happy with this (of course). Alternatively, if someone feels it is too restrictive, I guess we could also say the use of the lifetime option in solicit/advertise/... exchanges is beyond the scope of the document. This way we can implicitly tell implementors that they can only concentrate on the usage for information-requests while leaving a future possibility of extension. (just a thought, not intending to introduce further confusion...) 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 Aug 23 05:41:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24344; Mon, 23 Aug 2004 05:41:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzBAK-0003Vp-OV; Mon, 23 Aug 2004 05:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzB3D-0002dc-00 for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 05:23:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23624 for ; Mon, 23 Aug 2004 05:23:31 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzB3P-0000Pm-01 for dhcwg@ietf.org; Mon, 23 Aug 2004 05:23:51 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:d496:d9ca:8037:c688]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 38DA51525D; Mon, 23 Aug 2004 18:23:31 +0900 (JST) Date: Mon, 23 Aug 2004 18:23:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas In-Reply-To: <20040803033357.GA20506@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk Subject: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org (Sorry for the delay in response) I've changed the title since I'm concentrating on this particular issue. Instead of making a response to each sub-issue (attached below), let me raise a more fundamental concern. Perhaps I'm just pedantic, but the current behavior of the lifetime option, however clearly it is defined, does not sound like a "lifetime" that I would envision. To me, if a lifetime of some information expires, the information should be invalid (in some sense). But the current behavior described in dhc-lifetime-01 does not seem to invalidate the information in any way; the "lifetime" would rather seem like an "update timer" or something. One obvious "fix" to this is to change the option name to something like "Information Update Timer" option (too long?). However, I personally would like to leave the possibility of invalidating the information on lifetime expiry. With this sense I'd imagine something like this: - the option name ("lifetime option") is the same - the client starts re-sending Information-Requests at some point in time to the expiration. (e.g. a half of the lifetime) - even if the clients cannot get a response by the expiration, it should continue sending Information-requests. However, it can also invalidate the expired information in some way, e.g., by preferring a "last resort" default or by using other means of configuration. What do others think? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp >>>>> On Tue, 3 Aug 2004 05:33:57 +0200, >>>>> Stig Venaas said: >> Hoping it's not too late, here a couple of comments (or questions, >> actually) on the draft. >> >> 1. I'm still not really sure what the client should do for information >> when a lifetime expires. >> >> For example, the draft says in Section 3.1 that >> >> If client has received a lifetime with this option, and contacts >> server to receive new or update any existing data prior to its >> expiration, it SHOULD also update data covered by this option. If no >> new lifetime is received, it MUST behave as if no value was ever >> provided. >> >> I don't understand the scenario. Does this mean the following case? >> >> - The client sends an Information-request message, and gets a reply >> with a DNS server address (call it X) with lifetime of 1 hour. >> - 30 minutes later, the client happens to resend an >> Information-request message. This time, it gets a response, but >> the response does not contain either DNS server address X or a new >> lifetime. >> >> If this is an intended scenario, then what does "behave as if no >> value was ever provided"? Does it mean the client MUST treat >> address X as if it had infinite lifetime? Or does this mean the >> client MUST regard address X expired immediately? Or something >> else? > I'm open for anything. But my intention is that client behaves as if > it didn't get a lifetime in the first place. That is, just like it would > behave if it doesn't know a specific lifetime. Whether it's infinite or > not, depends on the client. > I don't think this scenario will be common anyway, but we should say > something. My thinking is that the last response is the authoritative > one, so new lifetime value overrides the old, and no lifetime means > ignore the old and behave like you haven't ever seen one. > Another option would be to keep using the last seen lifetime until > expiry, but I'm not sure that's better. > Very happy to see suggestions for alternative behaviour, or for text > changes that makes it more clear. >> Also, I don't understand what the client should do with DNS server >> address X when the lifetime expires and the client does not get any >> reply for the try to update the information. Should the client >> invalidate address X? Can/should it continue to use it? > I think it can be left to the client. The client will retry for a long > period of time, and would usually get updated info; the lifetime simply > says when to start this process. So you're talking about a rare failure > case. I think it's sensible to keep using the info, at least if there > is nothing to fall back to. > I'm thinking of the option as a hint to the client when it should try > to update the info. I'm not sure if we need to specify the failure > modes in detail. >> Even if the client can update the information of address X with a >> new lifetime, how can we regard the period from the time when the >> previous lifetime expires and the time when the client gets the new >> information? Should we temporarily invalidate the address during >> the update period? Or Can we continue to use it? Probably the >> latter makes sense when the client can update the information, but >> it does not really match my intuition of "expiration"... > My intention is definitely that you should continue using it. I guess > that should be made clear. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 05:49:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24806; Mon, 23 Aug 2004 05:49:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzBE1-0003t8-Hr; Mon, 23 Aug 2004 05:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzB7B-0002zE-EW for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 05:27:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23853 for ; Mon, 23 Aug 2004 05:27:38 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzB7N-0000Te-05 for dhcwg@ietf.org; Mon, 23 Aug 2004 05:27:58 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:d496:d9ca:8037:c688]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C24491525D for ; Mon, 23 Aug 2004 18:27:37 +0900 (JST) Date: Mon, 23 Aug 2004 18:27:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: References: <20040803171447.GA27805@sverresborg.uninett.no> <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 05 Aug 2004 02:03:03 +0900, >>>>> JINMEI Tatuya said: >> I agree with Stig - we've discussed this issue before and come to the >> conclusion that there is little extra overhead in delivering information >> that has not changed, so there should be a single lifetime - chosen to be >> the shortest lifetome of any of the client's parameters. > Okay, I'm fine with the "singe lifetime for all option parameters" > approach. In fact, I was just wondering without any particular > preference. > But I want the document to be more specific on this point because > other readers might wonder the same point. We should also restrict the position where the lifetime option can appear: it should only be able to appear at the "top level" of option hierarchy. In other wise, it must not appear as a sub-option of another option. 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 Aug 23 11:19:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15803; Mon, 23 Aug 2004 11:19:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGCT-0001Lm-A6; Mon, 23 Aug 2004 10:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFoS-0005OZ-Du for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 10:28:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11865 for ; Mon, 23 Aug 2004 10:28:37 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzFoe-00068E-Jj for dhcwg@ietf.org; Mon, 23 Aug 2004 10:28:59 -0400 Received: from [10.0.1.19] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 417251B205C for ; Mon, 23 Aug 2004 09:28:19 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Mon, 23 Aug 2004 10:28:12 -0400 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 23, 2004, at 5:23 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > - even if the clients cannot get a response by the expiration, it > should continue sending Information-requests. However, it can also > invalidate the expired information in some way, e.g., by preferring > a "last resort" default or by using other means of configuration. Can you think of a real-world scenario where this would be the right thing to do? I can't come up with one. For example, if we wanted to fall back to some sort of link-local protocol, this wouldn't help us, because it would take too long. I think that in just about any scenario where you'd think to benefit by switching to some other configuration scheme, the switch would happen much too late, using this mechanism, to be of any benefit. So I think that we'd really be better off, as you suggest, renaming this the update timer. If there's some other configuration mechanism to which we should fall back, I think we need another mechanism for deciding when to fall back to it, and that should probably be specified in the draft that describes the fallback mechanism. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 11:20:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15894; Mon, 23 Aug 2004 11:20:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGCT-0001M5-NX; Mon, 23 Aug 2004 10:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFq6-0005w6-OV for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 10:30:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12030 for ; Mon, 23 Aug 2004 10:30:19 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzFqL-0006AH-02 for dhcwg@ietf.org; Mon, 23 Aug 2004 10:30:42 -0400 Received: from [10.0.1.19] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 92F981B226B; Mon, 23 Aug 2004 09:30:05 -0500 (CDT) In-Reply-To: References: <20040803171447.GA27805@sverresborg.uninett.no> <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Re: one more comment about the lifetime option Date: Mon, 23 Aug 2004 10:30:03 -0400 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 23, 2004, at 5:27 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > We should also restrict the position where the lifetime option can > appear: it should only be able to appear at the "top level" of option > hierarchy. I think this is a good idea. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 11:34:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16808; Mon, 23 Aug 2004 11:34:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGG4-00029v-Pj; Mon, 23 Aug 2004 10:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzG6h-00008l-A7 for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 10:47:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13395 for ; Mon, 23 Aug 2004 10:47:27 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzG6w-0006Sv-9K for dhcwg@ietf.org; Mon, 23 Aug 2004 10:47:51 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7NEkSat002790; Mon, 23 Aug 2004 09:46:38 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7NEkQU04090; Mon, 23 Aug 2004 10:46:26 -0400 (EDT) From: Joe Quanaim To: JINMEI Tatuya / =?utf-8?q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89=09?=, Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Mon, 23 Aug 2004 10:45:02 -0400 User-Agent: KMail/1.5.4 References: <20040803033357.GA20506@sverresborg.uninett.no> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200408231045.02340.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > (Sorry for the delay in response) > > I've changed the title since I'm concentrating on this particular > issue. > > Instead of making a response to each sub-issue (attached below), let > me raise a more fundamental concern. > > Perhaps I'm just pedantic, but the current behavior of the lifetime > option, however clearly it is defined, does not sound like a > "lifetime" that I would envision. To me, if a lifetime of some > information expires, the information should be invalid (in some > sense). But the current behavior described in dhc-lifetime-01 does > not seem to invalidate the information in any way; the "lifetime" > would rather seem like an "update timer" or something. > > One obvious "fix" to this is to change the option name to something > like "Information Update Timer" option (too long?). > > However, I personally would like to leave the possibility of > invalidating the information on lifetime expiry. With this sense I'd > imagine something like this: > > - the option name ("lifetime option") is the same > - the client starts re-sending Information-Requests at some point in > time to the expiration. (e.g. a half of the lifetime) > - even if the clients cannot get a response by the expiration, it > should continue sending Information-requests. However, it can also > invalidate the expired information in some way, e.g., by preferring > a "last resort" default or by using other means of configuration. > > What do others think? I also noticed the difference in semantics for this option versus address=20 lifetimes. If the lifetime option means that any option associated with it is no longe= r=20 valid at expiration, then a client needs to start the message exchange befo= re=20 the lifetime expires. Otherwise, normal processing will leave a client=20 system without critical information (probably dns) for a second or two unde= r=20 normal processing. =46or example, when the lifetime expires, the options associated with it wi= ll be=20 removed from system configuration by the client. The client then restarts= =20 the message exchange including a delay for sending. If all goes well, the= =20 client receives a response and updates the system. During the exchange, mo= st=20 applications will have problems even if there have been no network changes. If the lifetime option simply represents a timer to update the associated=20 options, this problem goes away. The previously configured values can rema= in=20 in place while an exchange takes places. After the exchange the system can= =20 be updated, if necessary. I read the lifetime option as a timer. I did it this way defensively, sinc= e=20 it does not introduce (short lived) breakage. Perhaps, as you suggested, the better fix is to use half the lifetime opti= on=20 as a sort of t1 value. This brings it inline with address lifetime=20 semantics. This would require some rewording of the draft. Also, if this change is made, it is probably more important to specify a=20 minimum lifetime value so that half the configured lifetime does not cause = a=20 significant change in network usage. Bernie Volz has mentioned this alread= y. Thanks for bringing up this issue. Joe.=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 11:56:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18262; Mon, 23 Aug 2004 11:56:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGrE-0006wa-8v; Mon, 23 Aug 2004 11:35:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGTU-0003pi-7M for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 11:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15397 for ; Mon, 23 Aug 2004 11:11:00 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzGTj-0006vW-DW for dhcwg@ietf.org; Mon, 23 Aug 2004 11:11:24 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7NFAN2M018238; Mon, 23 Aug 2004 17:10:23 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7NFALKD002632; Mon, 23 Aug 2004 17:10:21 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 23 Aug 2004 17:10:21 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040823151021.GE1105@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> <200408231045.02340.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408231045.02340.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 23, 2004 at 10:45:02AM -0400, Joe Quanaim wrote: > JINMEI Tatuya / ???????????? wrote: > > (Sorry for the delay in response) > > > > I've changed the title since I'm concentrating on this particular > > issue. > > > > Instead of making a response to each sub-issue (attached below), let > > me raise a more fundamental concern. > > > > Perhaps I'm just pedantic, but the current behavior of the lifetime > > option, however clearly it is defined, does not sound like a > > "lifetime" that I would envision. To me, if a lifetime of some > > information expires, the information should be invalid (in some > > sense). But the current behavior described in dhc-lifetime-01 does > > not seem to invalidate the information in any way; the "lifetime" > > would rather seem like an "update timer" or something. > > One obvious "fix" to this is to change the option name to something > > like "Information Update Timer" option (too long?). Yes, the term lifetime is a bit misleading. I'm open for suggestions for other names. > > However, I personally would like to leave the possibility of > > invalidating the information on lifetime expiry. With this sense I'd > > imagine something like this: I don't see why you would want that. > > - the option name ("lifetime option") is the same > > - the client starts re-sending Information-Requests at some point in > > time to the expiration. (e.g. a half of the lifetime) > > - even if the clients cannot get a response by the expiration, it > > should continue sending Information-requests. However, it can also > > invalidate the expired information in some way, e.g., by preferring > > a "last resort" default or by using other means of configuration. > > > > What do others think? > > I also noticed the difference in semantics for this option versus address > lifetimes. > > If the lifetime option means that any option associated with it is no longer > valid at expiration, then a client needs to start the message exchange before > the lifetime expires. Otherwise, normal processing will leave a client > system without critical information (probably dns) for a second or two under > normal processing. Yes, that is no good. > For example, when the lifetime expires, the options associated with it will be > removed from system configuration by the client. The client then restarts > the message exchange including a delay for sending. If all goes well, the > client receives a response and updates the system. During the exchange, most > applications will have problems even if there have been no network changes. > > If the lifetime option simply represents a timer to update the associated > options, this problem goes away. The previously configured values can remain > in place while an exchange takes places. After the exchange the system can > be updated, if necessary. > > I read the lifetime option as a timer. I did it this way defensively, since > it does not introduce (short lived) breakage. > > Perhaps, as you suggested, the better fix is to use half the lifetime option > as a sort of t1 value. This brings it inline with address lifetime > semantics. This would require some rewording of the draft. I don't like this, sounds more complex than we need. > > Also, if this change is made, it is probably more important to specify a > minimum lifetime value so that half the configured lifetime does not cause a > significant change in network usage. Bernie Volz has mentioned this already. > > Thanks for bringing up this issue. I feel strongly that it should only tell the client when it should try to update the info (like t1 I guess). But the client should keep the info while it keeps trying to update the info. As I understand the DHCP spec, it will keep retransmitting the Information-Request indefinitely if necessary, which means that the config data also might be kept indefinitely. Of course there could be other reasons for the client to remove configuration, the lifetime spec shouldn't prevent that either. But that would be completely independent of the lifetime option. The reason we want the option, is to have some control of when a client tries to update its info. We're trying to solve problem stated in the problem statement. The point is not to ensure stateless info is removed at the host. Why would you want that? I agree the name is misleading. The draft should make clear what it is, but another name might help. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 12:29:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21099; Mon, 23 Aug 2004 12:29:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzH5r-0000qA-VE; Mon, 23 Aug 2004 11:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGoV-0006Nj-03 for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 11:32:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16653 for ; Mon, 23 Aug 2004 11:32:43 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzGoj-0007SK-QY for dhcwg@ietf.org; Mon, 23 Aug 2004 11:33:07 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i7NFWhgg017036 for ; Mon, 23 Aug 2004 16:32:43 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA17281 for ; Mon, 23 Aug 2004 16:32:41 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i7NFWe901156 for dhcwg@ietf.org; Mon, 23 Aug 2004 16:32:40 +0100 Date: Mon, 23 Aug 2004 16:32:40 +0100 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040823153240.GM31902@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <20040803033357.GA20506@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 23, 2004 at 10:28:12AM -0400, Ted Lemon wrote: > > So I think that we'd really be better off, as you suggest, renaming > this the update timer. If there's some other configuration mechanism > to which we should fall back, I think we need another mechanism for > deciding when to fall back to it, and that should probably be specified > in the draft that describes the fallback mechanism. The original idea for the "timer", as documented in the stateless-renumbering draft, was a "hint" for nodes to re-request information such that if there was a renumbering event, or a change in DNS, NTP, etc servers, the (stateless) node could learn of them. Without any timer, the node has no standard mechanisms for this (it could do so on receipt of a new prefix in an RA, but that doesn't cover new DNS servers being added). So I think "update timer" may be better. Is there any case for different behaviour for stateful and stateless nodes (i.e. based on the method the node's address was obtained from)? Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 14:21:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28374; Mon, 23 Aug 2004 14:21:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzJ6x-0001ZS-RS; Mon, 23 Aug 2004 14:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIqx-0007X3-Fv for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 13:43:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25486 for ; Mon, 23 Aug 2004 13:43:25 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzIrD-0001bW-47 for dhcwg@ietf.org; Mon, 23 Aug 2004 13:43:48 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7NHgfY1022199; Mon, 23 Aug 2004 12:42:42 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7NHgfU06769; Mon, 23 Aug 2004 13:42:41 -0400 (EDT) From: Joe Quanaim To: Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Mon, 23 Aug 2004 13:42:39 -0400 User-Agent: KMail/1.5.4 References: <200408231045.02340.jdq@lucent.com> <20040823151021.GE1105@sverresborg.uninett.no> In-Reply-To: <20040823151021.GE1105@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408231342.39913.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > I feel strongly that it should only tell the client when it should > try to update the info (like t1 I guess). But the client should > keep the info while it keeps trying to update the info. As I > understand the DHCP spec, it will keep retransmitting the > Information-Request indefinitely if necessary, which means that > the config data also might be kept indefinitely. I agree with this sentiment. If a client must remove configured information when the lifetime option expires, the client is punished. A client that did not implement the lifetime option could continue to use configured information. The option expiration is not necessarily indicative of a change in the network. It sounds like all that is needed is a new name for this option. Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 06:00:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19908; Tue, 24 Aug 2004 06:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzXi9-0003Q9-80; Tue, 24 Aug 2004 05:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzXW4-0000n5-Mx for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 05:22:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17566 for ; Tue, 24 Aug 2004 05:22:49 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzXWS-00048H-VA for dhcwg@ietf.org; Tue, 24 Aug 2004 05:23:22 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7O9MA2M018296; Tue, 24 Aug 2004 11:22:10 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7O9M9eW005707; Tue, 24 Aug 2004 11:22:09 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 24 Aug 2004 11:22:09 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040824092209.GA5677@sverresborg.uninett.no> References: <200408231045.02340.jdq@lucent.com> <20040823151021.GE1105@sverresborg.uninett.no> <200408231342.39913.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408231342.39913.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 23, 2004 at 01:42:39PM -0400, Joe Quanaim wrote: [...] > It sounds like all that is needed is a new name for this option. So let's try to find a new name. I think "update time option" is one possibility. I don't like "update timer option" because this is only a value to use for the timer, not the timer itself. Another alternative is "refresh time option" perhaps? I discussed it with a colleague, and we came up with alternatives like "suggested refresh/update time option" or "refresh/update within option". Not so sure about the last one, it tries to make it clear that you might refresh/update before the specified time. I think we should keep the name fairly short. We should have a name that isn't misleading, but people will still have to read the draft to understand exactly what it is. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 08:58:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02168; Tue, 24 Aug 2004 08:58:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzaZN-0001uG-Up; Tue, 24 Aug 2004 08:38:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bza9r-0006wn-4h for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 08:12:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28786 for ; Tue, 24 Aug 2004 08:12:04 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzaAG-00079x-UA for dhcwg@ietf.org; Tue, 24 Aug 2004 08:12:38 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:99cf:ebbf:eefe:5e4f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3071F15263; Tue, 24 Aug 2004 21:12:01 +0900 (JST) Date: Tue, 24 Aug 2004 21:12:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Mon, 23 Aug 2004 10:28:12 -0400, >>>>> Ted Lemon said: >> - even if the clients cannot get a response by the expiration, it >> should continue sending Information-requests. However, it can also >> invalidate the expired information in some way, e.g., by preferring >> a "last resort" default or by using other means of configuration. > Can you think of a real-world scenario where this would be the right > thing to do? I can't come up with one. The scenario I thought of is that if the "lifetime" of a DNS (recursive) server expires with no update I'd stop using the server and start a local recursive server daemon (e.g., run BIND named on my laptop and specify ::1 in /etc/resolv.conf) as a last resort. I'm quite sure that this is a "real world" scenario because I, for one, would like to have this feature and I'm living in the real world of the Internet. I admit this might be a niche demand though. I can also think of a scenario where I'll then prefer information from DHCPv4 (over the expired information from DHCPv6). But I don't know this makes sense in the real world. Aside from the scenarios, I'm also concerned about a (possible) pitfall with the "update timer" semantics. Assume that we have a reply to Information-request containing a DNS server address X with update timer (or lifetime) T. T seconds later, the client will restart Information-request/reply exchanges. If we then get a different DNS server address Y, we'll stop using the old address X and switch to Y. This should exactly be the "renumbering scenario", and the behavior looks reasonable. But what if the reply does not contain any new DNS server address? Can we still continue to use address X, or will we then lose any usable DNS server address? If the former is the intent, it seems a bit odd to me that the behavior is different based on whether the replied set is empty or not (at least the specification is not very clear on this). If the latter is the intent, doesn't it almost mean we invalidate the expired information X? Anyway...so far, others do not seem to be very happy with the idea of invalidating expired information. If the above explanation is still not so convincing, I won't stick to the idea. I can live with the "update timer" semantics as long as the specification is clear enough to implement. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. I'm afraid I won't be able to be very active on the list this week. I'd apologize in advance for future delay of my responses. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 10:19:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09153; Tue, 24 Aug 2004 10:19:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzboL-0001OW-9h; Tue, 24 Aug 2004 09:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzbKn-0003kg-Sl for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 09:27:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03961 for ; Tue, 24 Aug 2004 09:27:26 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzbLD-00008h-Uu for dhcwg@ietf.org; Tue, 24 Aug 2004 09:28:01 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7ODQt2M021483; Tue, 24 Aug 2004 15:26:55 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7ODQoEp006265; Tue, 24 Aug 2004 15:26:50 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 24 Aug 2004 15:26:50 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040824132650.GI5677@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dhcwg@ietf.org, Ted Lemon 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 24, 2004 at 09:12:01PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Mon, 23 Aug 2004 10:28:12 -0400, > >>>>> Ted Lemon said: > > >> - even if the clients cannot get a response by the expiration, it > >> should continue sending Information-requests. However, it can also > >> invalidate the expired information in some way, e.g., by preferring > >> a "last resort" default or by using other means of configuration. > > > Can you think of a real-world scenario where this would be the right > > thing to do? I can't come up with one. > > The scenario I thought of is that if the "lifetime" of a DNS > (recursive) server expires with no update I'd stop using the server > and start a local recursive server daemon (e.g., run BIND named on my > laptop and specify ::1 in /etc/resolv.conf) as a last resort. I'm > quite sure that this is a "real world" scenario because I, for one, > would like to have this feature and I'm living in the real world of > the Internet. I admit this might be a niche demand though. > > I can also think of a scenario where I'll then prefer information > from DHCPv4 (over the expired information from DHCPv6). But I don't > know this makes sense in the real world. OK, I can see that. How about adding this: The expiry of the lifetime in itself does not in anyway mean that the client should remove the data. The client should keep it's current data while attempting to refresh it. The client is however free to fall back to other mechanisms if it cannot refresh the data within a reasonable amount of time. It's a bit vague, but I don't think we should standardize every detail. > Aside from the scenarios, I'm also concerned about a (possible) > pitfall with the "update timer" semantics. > > Assume that we have a reply to Information-request containing a DNS > server address X with update timer (or lifetime) T. T seconds later, > the client will restart Information-request/reply exchanges. If we > then get a different DNS server address Y, we'll stop using the old > address X and switch to Y. This should exactly be the "renumbering > scenario", and the behavior looks reasonable. But what if the reply > does not contain any new DNS server address? Can we still continue to > use address X, or will we then lose any usable DNS server address? It is reasonable to remove it in my opinion. However if the client has no fallback mechanism to obtain a new resolver address, I guess it could decide to keep using it. If however say NTP server address is removed, and the client has no fallback, I would say disable NTP. Try to think what you would do without this option. Your client would try to refresh the info at some point wouldn't it? If you move to new link, if user requests it etc. What do you do if no server is specified in the reply? If the DNS server address is not in the new reply, the administrator has removed it from the DHCP server config, and is expecting clients to obtain DNS server address in some other way, or? It's just another hint for when to update the info. Also, if you stop offering some service, or by accident include something. There should be a way to remove it. > If the former is the intent, it seems a bit odd to me that the > behavior is different based on whether the replied set is empty or not > (at least the specification is not very clear on this). If the latter > is the intent, doesn't it almost mean we invalidate the expired > information X? > > Anyway...so far, others do not seem to be very happy with the idea of > invalidating expired information. If the above explanation is still > not so convincing, I won't stick to the idea. I can live with the > "update timer" semantics as long as the specification is clear enough > to implement. Well, I'm interested in hearing what you think is reasonable, and what you would implement in your client if you don't have this options, but renew the data for other reasons. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > p.s. I'm afraid I won't be able to be very active on the list this > week. I'd apologize in advance for future delay of my responses. NP. I hope to post my suggestions for next revision later this week. I'll then wait several days to see if people are satisfied, in which case I'll make it the official "02" version. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 11:07:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13123; Tue, 24 Aug 2004 11:07:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzcQ3-0007AC-Cm; Tue, 24 Aug 2004 10:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzcFt-0004dN-TS for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 10:26:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09731 for ; Tue, 24 Aug 2004 10:26:26 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzcGK-0001VI-Sx for dhcwg@ietf.org; Tue, 24 Aug 2004 10:27:02 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i7OEPkvV023190; Tue, 24 Aug 2004 09:25:46 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7OEPjP08499; Tue, 24 Aug 2004 10:25:45 -0400 (EDT) From: Joe Quanaim To: Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Tue, 24 Aug 2004 10:25:11 -0400 User-Agent: KMail/1.5.4 References: <200408231342.39913.jdq@lucent.com> <20040824092209.GA5677@sverresborg.uninett.no> In-Reply-To: <20040824092209.GA5677@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408241025.11357.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > On Mon, Aug 23, 2004 at 01:42:39PM -0400, Joe Quanaim wrote: > [...] > > > It sounds like all that is needed is a new name for this option. > > So let's try to find a new name. I think "update time option" is > one possibility. I don't like "update timer option" because this > is only a value to use for the timer, not the timer itself. > > Another alternative is "refresh time option" perhaps? > > I discussed it with a colleague, and we came up with alternatives > like "suggested refresh/update time option" or "refresh/update > within option". Not so sure about the last one, it tries to make > it clear that you might refresh/update before the specified time. > > I think we should keep the name fairly short. We should have a > name that isn't misleading, but people will still have to read the > draft to understand exactly what it is. Another alternative might be "refresh delay". This changes the nature of the name from "check back in n seconds" to "do not check again until at least n seconds". It does not piggyback on the notion of expiration, which is well defined in the address management side of dhcp, but not on the stateless option side. Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 11:54:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16882; Tue, 24 Aug 2004 11:54:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzdGB-0000dn-MO; Tue, 24 Aug 2004 11:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzcue-0005Zo-QY for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 11:08:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13224 for ; Tue, 24 Aug 2004 11:08:38 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzcvC-0002Jr-3P for dhcwg@ietf.org; Tue, 24 Aug 2004 11:09:14 -0400 Received: from [10.0.1.2] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 3E2401B232D for ; Tue, 24 Aug 2004 10:08:13 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Tue, 24 Aug 2004 11:08:14 -0400 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 8:12 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > The scenario I thought of is that if the "lifetime" of a DNS > (recursive) server expires with no update I'd stop using the server > and start a local recursive server daemon (e.g., run BIND named on my > laptop and specify ::1 in /etc/resolv.conf) as a last resort. I'm > quite sure that this is a "real world" scenario because I, for one, > would like to have this feature and I'm living in the real world of > the Internet. I admit this might be a niche demand though. I would never want to suggest that your needs as a network user are not representative of the average user, of course! :') However, let's consider your scenario a little more closely. You acquire some information from the DHCP server. Subsequently, for some reason, it becomes impossible for the server to respond to the client. I have a couple of observations about this. First, the time at which it becomes impossible for the server to respond is not the same as the time at which the client attempts to refresh its configuration information. The two events are unrelated. Second, we should consider why the DHCP server is no longer able to respond. I would say the most likely scenario is that I am no longer connected to the same link, so that my routing information is stale. But in this case I am going to notice that I am no longer on the same link because of RA messages, or because of a physical network link state transition. And this will happen at the time when it becomes impossible to contact the DHCP server, *not* at the time that the refresh time comes. So I would say in this case that you will already have invalidated the refresh timer and the information covered by the refresh timer, so we have no need to say what you would do when the refresh timer expired, because it will not ever expire. Another scenario that might occur is that the DHCP server might be turned off, and then it wouldn't reply because it's not available. In this case, I can think of two basic reasons why this might have happened. One is that the server needs some kind of maintenance. The other is that DHCP service is no longer wanted on the link. In the first case, you want to continue using the configuration information, because it's still valid. It would be somewhat disastrous to stop using it. In the second case, which I would argue is unlikely on a production network, it would be nice if there was some way to indicate that the information was no longer valid. I would say that if you want to address the concern you've raised, this is the scenario that you need to address, and that the solution you've proposed doesn't fit the scenario you've described, because in the most common case where you care, the solution isn't needed, and in the second-most-common case, the proposed solution would result in the network becoming unusable to the average user. > I can also think of a scenario where I'll then prefer information > from DHCPv4 (over the expired information from DHCPv6). But I don't > know this makes sense in the real world. This is a fertile area of DHCP research. :') > Assume that we have a reply to Information-request containing a DNS > server address X with update timer (or lifetime) T. T seconds later, > the client will restart Information-request/reply exchanges. If we > then get a different DNS server address Y, we'll stop using the old > address X and switch to Y. This should exactly be the "renumbering > scenario", and the behavior looks reasonable. But what if the reply > does not contain any new DNS server address? Can we still continue to > use address X, or will we then lose any usable DNS server address? It's a good question. I think that it's unlikely that the DNS server address would be missing unless the server had been configured to no longer send it, so I think it would indeed make sense to stop using the stale information. This could be the answer to the scenario you proposed initially - if you want to turn off the DHCP server, you configure it to send an empty information reply message. You leave it configured this way for the duration of the refresh time. Then you turn it off, because you can be confident that any client that was connected to the network during the interval when it was sending empty information reply messages will no longer be relying on DHCP for the information the DHCP server had been providing. This implies that if we *start up* on a link to which we were previously connected, we should immediately attempt to contact the DHCP server. In this case, if we are not able to contact the DHCP server by the time the refresh time has passed, we can assume that it is no longer active on the link, and that any information we have cached is no longer valid. This would be analogous to the INIT-REBOOT state in DHCPv4. > p.s. I'm afraid I won't be able to be very active on the list this > week. I'd apologize in advance for future delay of my responses. I would like to defer making a decision on this point until you have time to respond, so if that's next week, let's wait until next week to resolve these issues. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From yklzv@yahoo.com Tue Aug 24 19:12:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21655; Tue, 24 Aug 2004 19:12:23 -0400 (EDT) Received: from stmartin-1-82-225-130-167.fbx.proxad.net ([82.225.130.167]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BzkTN-00039h-NH; Tue, 24 Aug 2004 19:13:04 -0400 Received: from 34.16.36.222 by web630.mail.yahoo.com; Tue, 24 Aug 2004 22:09:17 -0200 Message-ID: From: "Rosie Mcdermott" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive s0ftware at incredibly low prices Date: Wed, 25 Aug 2004 04:03:17 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--88467881252061976" X-CS-IP: 20.0.26.104 X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----88467881252061976 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable TOP quality software:

Special Offer #1:
Windows X= P Professional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe - Pho= toshop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macrome= dia Dreamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Her= e











?2N47A3zVjC9Xk2ythoroughbred|d= hcipv6-archive@ietf.org">or un*su*bs*cr*ibe =20 ----88467881252061976-- From dhcwg-bounces@ietf.org Tue Aug 24 21:54:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02805; Tue, 24 Aug 2004 21:54:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmZ8-0005qU-9V; Tue, 24 Aug 2004 21:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzm4z-0000qU-Hb for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 20:55:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28532 for ; Tue, 24 Aug 2004 20:55:50 -0400 (EDT) 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.33) id 1Bzm5W-0004xU-F1 for dhcwg@ietf.org; Tue, 24 Aug 2004 20:56:31 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2004 18:00:17 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7P0tGiQ020140; Tue, 24 Aug 2004 17:55:17 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-156.cisco.com [10.86.240.156]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALB56826; Tue, 24 Aug 2004 20:55:16 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" , =?utf-8?B?J0pJTk1FSSBUYXR1eWEgLyDCkF/igJPCvuKAmULCjcOGJw==?= Subject: RE: [dhcwg] Re: one more comment about the lifetime option Date: Tue, 24 Aug 2004 20:55:14 -0400 Organization: Cisco Message-ID: <001401c48a3e$2ededf20$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable If it is restricted to a REPLY to an INFORMATION-REQUEST, there is no = need for this explicit statement as that's all that is currently = possible - there are no IA_NA, IA_TA, or IA_PD options for these = messages. > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Monday, August 23, 2004 10:30 AM > To: JINMEI Tatuya / =C2=90_=E2=80=93=C2=BE=E2=80=99B=C2=8D=C3=86 > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Re: one more comment about the lifetime option >=20 >=20 > On Aug 23, 2004, at 5:27 AM, JINMEI Tatuya / = =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > We should also restrict the position where the lifetime option can > > appear: it should only be able to appear at the "top level"=20 > of option=20 > > hierarchy. >=20 > I think this is a good idea. >=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 From dhcwg-bounces@ietf.org Tue Aug 24 21:57:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03020; Tue, 24 Aug 2004 21:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmaG-0006D6-5V; Tue, 24 Aug 2004 21:28:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmAJ-0001so-2a for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 21:01:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28944 for ; Tue, 24 Aug 2004 21:01:25 -0400 (EDT) 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.33) id 1BzmAv-00056B-1O for dhcwg@ietf.org; Tue, 24 Aug 2004 21:02:06 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Aug 2004 18:07:24 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7P10jox010599; Tue, 24 Aug 2004 18:00:46 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-156.cisco.com [10.86.240.156]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALB57036; Tue, 24 Aug 2004 21:00:47 -0400 (EDT) From: "Bernie Volz" To: , "'Stig Venaas'" Subject: RE: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) Date: Tue, 24 Aug 2004 21:00:45 -0400 Organization: Cisco Message-ID: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200408241025.11357.jdq@lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'd vote for "Refresh Time Option". I have no problem renaming this and = I do how we keep it simple - client should refresh its data when the time = elapses (note that this doesn't preclude the client from doing it earlier if it = has a good reason to do so). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Joe Quanaim > Sent: Tuesday, August 24, 2004 10:25 AM > To: Stig Venaas > Cc: dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] behavior on lifetime expiration (Re:=20 > comments ondraft-ietf-dhc-lifetime-01.txt) >=20 >=20 > Stig Venaas wrote: > > On Mon, Aug 23, 2004 at 01:42:39PM -0400, Joe Quanaim wrote: [...] > > > > > It sounds like all that is needed is a new name for this option. > > > > So let's try to find a new name. I think "update time=20 > option" is one=20 > > possibility. I don't like "update timer option" because=20 > this is only a=20 > > value to use for the timer, not the timer itself. > > > > Another alternative is "refresh time option" perhaps? > > > > I discussed it with a colleague, and we came up with=20 > alternatives like=20 > > "suggested refresh/update time option" or "refresh/update within=20 > > option". Not so sure about the last one, it tries to make it clear=20 > > that you might refresh/update before the specified time. > > > > I think we should keep the name fairly short. We should have a name=20 > > that isn't misleading, but people will still have to read=20 > the draft to=20 > > understand exactly what it is. >=20 > Another alternative might be "refresh delay". This changes=20 > the nature of the=20 > name from "check back in n seconds" to "do not check again=20 > until at least n=20 > seconds". It does not piggyback on the notion of expiration,=20 > which is well=20 > defined in the address management side of dhcp, but not on=20 > the stateless=20 > option side. >=20 > Joe. >=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 From dhcwg-bounces@ietf.org Tue Aug 24 22:03:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03616; Tue, 24 Aug 2004 22:03:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzmk9-0007uW-Au; Tue, 24 Aug 2004 21:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmLJ-00047X-7h for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 21:12:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29952 for ; Tue, 24 Aug 2004 21:12:42 -0400 (EDT) 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.33) id 1BzmLr-0005QH-2X for dhcwg@ietf.org; Tue, 24 Aug 2004 21:13:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2004 18:17:09 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7P1C5We022866; Tue, 24 Aug 2004 18:12:06 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-156.cisco.com [10.86.240.156]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALB57532; Tue, 24 Aug 2004 21:12:06 -0400 (EDT) From: "Bernie Volz" To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?= , "'Ted Lemon'" Subject: RE: [dhcwg] behavior on lifetime expiration (Re: commentson draft-ietf-dhc-lifetime-01.txt) Date: Tue, 24 Aug 2004 21:12:07 -0400 Organization: Cisco Message-ID: <001601c48a40$8a411e80$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Jinmei: You'd prefer IPv4 based information over IPv6? And DHCPv4, if Inform was used, doesn't have *ANY* time to expire the information - so I don't think you'd want to use this information in preference to DHCPv6 information with a time? If you can't obtain newer information, you're always free to take = whatever steps you like on the client - ie, start a local recursive server daemon (e.g., run BIND named on my laptop and specify ::1 in /etc/resolv.conf). The issue of not receiving some information that was previously received = is a good one and we probably should give some advice in the draft as to possible options that a client could chose (based on "local" policy). My = own feeling is that I'd discard the old information and use the new, = especially if the source can be trusted (ie, authentication was used). There may be valid reasons why some options are no longer available; in other cases = it could be a configuration error and in that case it may be good for administrators to know about it sooner than later. The worst is if it is = a Denial of Service attack, but in that case they can just as easily send = you bogus information. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of JINMEI Tatuya / =90_=96=BE=92B=8D=C6 > Sent: Tuesday, August 24, 2004 8:12 AM > To: Ted Lemon > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] behavior on lifetime expiration (Re:=20 > commentson draft-ietf-dhc-lifetime-01.txt) >=20 >=20 > >>>>> On Mon, 23 Aug 2004 10:28:12 -0400, > >>>>> Ted Lemon said: >=20 > >> - even if the clients cannot get a response by the expiration, it=20 > >> should continue sending Information-requests. However, it=20 > can also=20 > >> invalidate the expired information in some way, e.g., by=20 > preferring a=20 > >> "last resort" default or by using other means of configuration. >=20 > > Can you think of a real-world scenario where this would be=20 > the right=20 > > thing to do? I can't come up with one. >=20 > The scenario I thought of is that if the "lifetime" of a DNS > (recursive) server expires with no update I'd stop using the=20 > server and start a local recursive server daemon (e.g., run=20 > BIND named on my laptop and specify ::1 in /etc/resolv.conf)=20 > as a last resort. I'm quite sure that this is a "real world"=20 > scenario because I, for one, would like to have this feature=20 > and I'm living in the real world of the Internet. I admit=20 > this might be a niche demand though. >=20 > I can also think of a scenario where I'll then prefer=20 > information from DHCPv4 (over the expired information from=20 > DHCPv6). But I don't know this makes sense in the real world. >=20 > Aside from the scenarios, I'm also concerned about a=20 > (possible) pitfall with the "update timer" semantics. >=20 > Assume that we have a reply to Information-request containing=20 > a DNS server address X with update timer (or lifetime) T. T=20 > seconds later, the client will restart=20 > Information-request/reply exchanges. If we then get a=20 > different DNS server address Y, we'll stop using the old=20 > address X and switch to Y. This should exactly be the=20 > "renumbering scenario", and the behavior looks reasonable. =20 > But what if the reply does not contain any new DNS server=20 > address? Can we still continue to use address X, or will we=20 > then lose any usable DNS server address? >=20 > If the former is the intent, it seems a bit odd to me that=20 > the behavior is different based on whether the replied set is=20 > empty or not (at least the specification is not very clear on=20 > this). If the latter is the intent, doesn't it almost mean=20 > we invalidate the expired information X? >=20 > Anyway...so far, others do not seem to be very happy with the=20 > idea of invalidating expired information. If the above=20 > explanation is still not so convincing, I won't stick to the=20 > idea. I can live with the "update timer" semantics as long=20 > as the specification is clear enough to implement. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > p.s. I'm afraid I won't be able to be very active on the list=20 > this week. I'd apologize in advance for future delay of my responses. >=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 admin@computeradmin.org Wed Aug 25 00:38:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13408; Wed, 25 Aug 2004 00:38:15 -0400 (EDT) Received: from [61.189.236.152] (helo=JY-D1YM9FKDZI67) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BzpYl-0000vh-Ku; Wed, 25 Aug 2004 00:39:00 -0400 Received: from fb.24hq.net [5.83.34.126] by JY-D1YM9FKDZI67 with SMTP for ; Wed, 25 Aug 2004 11:39:19 +0600 Message-ID: From: "Administrator" To: dhcipv6-archive@ietf.org Subject: Staff Bulletin Date: Wed, 25 Aug 04 11:39:19 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="95_2_FACD08._8ACF_E4" X-Spam-Score: 32.7 (++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 This is a multi-part message in MIME format. --95_2_FACD08._8ACF_E4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Staff Members: You Must Respond By 5 P.M. Thursday, August 26, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand Notebook computers at more than 50% off MSRP to all Staff Members who respond to this message before 5 P.M., Thursday, August 26, 2004. All Notebooks are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Notebooks are lightweight and fully Equipped with the Next Generation WiFi technology, making these The very best performing computers that money can buy. Avtech Computers is offering these feature rich, top performing Notebooks With the latest Wireless technology at an amazing price To all who call: : 1-800-318-1388 by 5 P.M. Thursday, August 26, 2004 AT-1000S Notebook Series- The ultimate combination of innovative mobile features and practical value= . * 1 Giga Pro Transmeta Crusoe Mobile CPU for incredible power * 128 MB Super Fast DDR SDRAM at 400MHz (Upgradeable to 256 MB) * 20 GB ATA100 Hard Drive (Upgradeable to 30GB ATA100 Hard Drive) * CD-Rom Drive (Upgradeable to DVD/CDRW) * Next Generation 802.11 Wireless Technology for total WiFi freedom * 14.1 XGA TFT Ultra Sharp Liquid Display * Premium Sound and Video * Enhanced Front Stereo Speakers * Total Connectivity 56K V.90 Performance Pro Fax Modem * Integrated High Performance Intel=FFFFFFAE 10/100 LAN Gigabit Ethernet * TV-Out Port with S-Video and USB 2.0 Ports * Soft Touch Keyboard * Programmable Synaptics Touchpad Mouse * Internet and Network Ready * Extra Long Life Battery Pack * Full Range 160Watt AC Adapter * 1 Year parts and labor warranty * Priority Customer Service and Toll Free Technical Support * Latest Qualified Drivers Installed MSRP $1299 .......................................... Your Cost $597 Avtech/ASUS AT-2500 The AT-2500, using the latest technology by ASUS, achieves a perfect blend= of style and performance at a remarkable price. Quantities for this super fast and extremely reliable notebook computer are strictly limited to supplies on hand. The AT-2500 Notebook by ASUS Features: * 2.0 GHz Intel Processor * 15.0" SXGA+ active matrix color Display for an amazing picture * ASUS ADTD II heat dissipation technology for a quieter computer that consumes less power * 20 GB Hard Drive with Ultra DMA100 support. (Upgradeable to/80 GB) * 256 MB Dual Channel DDR SDRam (Upgradeable to 1024MB) * CDRW / DVD combo drive (Upgradeable to DVD RW) * SoundBlaster Pro audio Build-in stereo speakers * 5 USB 2.0 ports, 56K V90 Fax Modem, 10/100BaseT PCI LAN on board * Serial port, Parallel port, TV Out, S-Video, IEEE 1394 port Fire wire, SIR port, PCMCIA 2.1 * Full size 88key Keyboard with MS-Windows function keys * Built-in Touch pad pointing device ASUS Power4 Gear Technology effectively adjusts CPU & LCD to maximize battery life * 8 cell Long Life Smart Battery * Advanced Asus Step power management technology * 2 year ASUS Warranty MSRP $1999 .......................................... Your Cost $997 How to qualify: 1. You must be a Nonprofit or School Staff Member. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-318-1388 by 5 P.M. Thursday, August 26, 2004 and we will hold the computers you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-318-1388 before 5 P.M. Thursday, August 26, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --95_2_FACD08._8ACF_E4-- From dhcwg-bounces@ietf.org Wed Aug 25 08:58:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11573; Wed, 25 Aug 2004 08:58:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzwz1-00050x-D5; Wed, 25 Aug 2004 08:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxYfR-0004Yw-87 for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 18:12:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25450 for ; Wed, 18 Aug 2004 18:12:22 -0400 (EDT) Received: from omta1.cgnet.com ([64.95.130.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxYlf-00048C-Cs for dhcwg@ietf.org; Wed, 18 Aug 2004 18:18:56 -0400 Received: from [64.95.130.10] (helo=smta-hub-2.cgnet.com) by omta1.cgnet.com with esmtp (Exim 4.41) id 1BxYfF-0007tp-Pb for dhcwg@ietf.org; Wed, 18 Aug 2004 15:12:13 -0700 Received: from dispatcher2-out.cgnet.com ([198.93.224.251]) by smta-hub-2.cgnet.com (PMDF V6.2 #30816) with ESMTP id <0I2N00655XOD1R@smta-hub-2.cgnet.com> for dhcwg@ietf.org; Wed, 18 Aug 2004 15:12:13 -0700 (PDT) Received: from [64.95.129.142] (helo=csimail1.CGNETAD.COM) by dispatcher2.cgnet.com with esmtp (Exim 4.41) id 1BxYfE-0003wV-D4 for dhcwg@ietf.org; Wed, 18 Aug 2004 15:12:12 -0700 Date: Wed, 18 Aug 2004 15:12:11 -0700 From: "Romero, Eric" To: dhcwg@ietf.org Message-id: <39A1B547DAD9D94A8C9A8A639C65A2CA037EDDCE@csimail1.CGNETAD.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: Windows2003 microsoft dhcp Thread-Index: AcSFcGja/hzhhOkgSG+x8gPzjyrOyQ== Content-class: urn:content-classes:message X-cgnet-com-MailScanner-Information: Please contact the ISP for more information X-cgnet-com-MailScanner: Found to be clean X-MailScanner-From: eric@csi.exch.cgnet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 25 Aug 2004 08:34:29 -0400 Subject: [dhcwg] Windows2003 microsoft dhcp 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi all, I have a Microsoft windows2003 domain running Microsoft DHCP, I want to = know what is the best way to assign ips securely. i.e if a vendor comes to the office I do not want his/her latop to = obtain an ip, ips must be assigned just to office's computers. thx _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 09:05:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12028; Wed, 25 Aug 2004 09:05:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzx2P-0005eJ-9h; Wed, 25 Aug 2004 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKPH-0003t0-Py; Thu, 12 Aug 2004 14:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21361; Thu, 12 Aug 2004 14:34:30 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvKUH-0001Pr-5Q; Thu, 12 Aug 2004 14:39:42 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Thu, 12 Aug 2004 11:33:57 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 11:33:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 11:33:29 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 12 Aug 2004 11:33:01 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2004 11:33:31 -0700 Message-ID: Thread-Topic: Stateful != M , Stateless != O thread-index: AcSAjrxJxtT3hzWySXSPpNgKHzFcgwAC7aeQ From: "Christian Huitema" To: "Bernie Volz" , "Ralph Droms" , X-OriginalArrivalTime: 12 Aug 2004 18:33:01.0847 (UTC) FILETIME=[CC8F2A70:01C4809A] X-Spam-Score: 0.4 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 25 Aug 2004 08:37:59 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] RE: Stateful != M , Stateless != O 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > If M is set(1), a client able to do stateful, does stateful (or full 3315) > and ignores the O bit.=20 More precisely, the M bit indicates that a client wishing to do stateful may do it, and the M=3D0 bit indicates that the client should not try. If the router wants to not enable stateless, then the M bit is not the right tool. The router should simply not advertise that prefixes are available for stateless auto-configuration. -- Christian Huitema _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 09:05:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12105; Wed, 25 Aug 2004 09:05:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzx2O-0005eE-V3; Wed, 25 Aug 2004 08:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuzXb-0007kO-5u for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 16:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08830 for ; Wed, 11 Aug 2004 16:17:41 -0400 (EDT) Received: from web90104.mail.scd.yahoo.com ([66.218.94.75]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BuzcO-0000DZ-LB for dhcwg@ietf.org; Wed, 11 Aug 2004 16:22:42 -0400 Message-ID: <20040811201710.54895.qmail@web90104.mail.scd.yahoo.com> Received: from [216.66.236.13] by web90104.mail.scd.yahoo.com via HTTP; Wed, 11 Aug 2004 13:17:10 PDT Date: Wed, 11 Aug 2004 13:17:10 -0700 (PDT) From: donna prescott To: dhcwg@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.3 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Wed, 25 Aug 2004 08:37:59 -0400 Subject: [dhcwg] Key Logger/Hacker/ serious using DHCP Server Hacked into my system/company 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="===============0587548894==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0587548894== Content-Type: multipart/alternative; boundary="0-1518279392-1092255430=:48943" --0-1518279392-1092255430=:48943 Content-Type: text/plain; charset=us-ascii These people are destroying my company, already they've hacked into 3 of our computers, gotten our accounting system so screwed up I have no idea what we are going to do if they can't be stopped before tax season if we are still in business by than. This is the information I have: I know it's a Mac computer or a mac server, any help would greatly be appriciated. Donna Prescott, Exotic Wood Dreams Internet Protocal (TCP/ IP) address assigned by DHPC physical address: 00-0C-FI-EE-BA-B3 I think my address: IP address: 192.168.0.100 Subnet Mask: 255.255.255.0 Default Gateway: 192.168.0.1 DHCP Server 192.168.0.1 Lease Obtained: 8/11/2004 8:50:43 AM Lease Expires: 8/18/2004 8:50: 43 AM DNS Server 192.168.0.1 Wins Server (blank) Thank You, T. & D. Prescott, Exotic Wood Dreams @ www.exoticwooddreams.com (909) 681-1855 Fax (909) 361-4411 Dedicated to: 'Making Parrot Dreams Come True' --0-1518279392-1092255430=:48943 Content-Type: text/html; charset=us-ascii
These people are destroying my company, already they've hacked into 3 of our computers, gotten our accounting system so screwed up I have no idea what we are going to do if they can't be stopped before tax season if we are still in business by than.
This is the information I have:   I know it's a Mac computer or a mac server, any help would greatly be appriciated.
Donna Prescott,
Exotic Wood Dreams
 
 Internet Protocal  (TCP/ IP)
address assigned by DHPC
physical address: 00-0C-FI-EE-BA-B3  
I think my address: IP address: 192.168.0.100
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.0.1
DHCP Server  192.168.0.1
Lease Obtained: 8/11/2004  8:50:43 AM
Lease Expires: 8/18/2004 8:50: 43 AM
DNS Server 192.168.0.1
Wins Server  (blank)
 


Thank You,
T. & D. Prescott,
Exotic Wood Dreams
(909) 681-1855  Fax (909) 361-4411
Dedicated to: 'Making Parrot Dreams Come True'
--0-1518279392-1092255430=:48943-- --===============0587548894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0587548894==-- From dhcwg-bounces@ietf.org Wed Aug 25 09:06:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12176; Wed, 25 Aug 2004 09:06:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzx2P-0005eR-KJ; Wed, 25 Aug 2004 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BztaA-0008NP-2T; Wed, 25 Aug 2004 04:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25761; Wed, 25 Aug 2004 04:56:31 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bztal-0005Kj-61; Wed, 25 Aug 2004 04:57:16 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z00H85VGG2S@mailout2.samsung.com>; Wed, 25 Aug 2004 17:55:28 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00FISVFG4M@mailout2.samsung.com>; Wed, 25 Aug 2004 17:54:53 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPSA id <0I2Z006FWVFESO@mmp1.samsung.com>; Wed, 25 Aug 2004 17:54:52 +0900 (KST) Date: Wed, 25 Aug 2004 14:24:51 +0530 From: "O.L.N.Rao" To: surya_pc@huawei.com Message-id: <04d601c48a81$304ea050$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <008f01c48a71$3b09c4d0$5c04120a@suryapc> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 25 Aug 2004 08:37:59 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: DHCPv6 Relay Queries. 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Surya, See my comments inline :) [PS: This is related to DHCPv6 and would be better to discuss in dhcwg@ietf.org] Regards, O. L. N. Rao & Suman V N ----- Original Message ----- From: "Surya" To: Sent: Wednesday, August 25, 2004 12:30 PM Subject: DHCPv6 Relay Queries. > Hi, > > Could you please clarify on the below mentioned queries on DHCPv6 Relay > > When we use the following topology > > "Client ----- Relay1 -------Relay 2 ---------Server" > > 1) Does all the DHCP messages from Client goes to Relay even after knowing > the server? ==> Yes, they always go to/through Relay. However, if the DHCPv6 client supports "Server Unicast Option", then DHCPv6 Server will send its unicast address to DHCPv6 Client. DHCPv6 Client will then use unicast communication with server. Here, I would like to mention one more point. Even though, the messages are sent to DHCPv6_All_Agents_and_Servers the Server Identifier option specifies the DHCPv6 server to which the message was intended. > > 2. Relay forms Relay forward message when it sends to another relay, will it > again construct a relay forward message? ===> Yes. Because, unless the total path is known, the reply can not come back in the same path. The server constructs the Relay-Reply message with the full path in Relay Message Options. > > 3. DHCP message can be can be stored in Options field of the Relay forward. > When it reaches the last relay on the network which is connected to Server, > how the processing should be? > ===> The Relay-Forward messages reaches Server as it is. > > Thanks > Surya. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 11:50:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25484; Wed, 25 Aug 2004 11:50:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzziW-0002XV-Vn; Wed, 25 Aug 2004 11:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzzVt-0000vr-Bt for dhcwg@megatron.ietf.org; Wed, 25 Aug 2004 11:16:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22844 for ; Wed, 25 Aug 2004 11:16:30 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzzWY-0003pm-GK for dhcwg@ietf.org; Wed, 25 Aug 2004 11:17:19 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7PFFx2M004670 for ; Wed, 25 Aug 2004 17:15:59 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7PFFx8B009282 for dhcwg@ietf.org; Wed, 25 Aug 2004 17:15:59 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 25 Aug 2004 17:15:59 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20040825151559.GJ5677@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I've tried to update the text based on all the suggestions and comments received. I may still try to improve the language, but please read the text below and let me know if you have problems with what it says. Lines from the draft are prefixed by "|". I have some comments/questions inline. I'm hoping that we can come to agreement on the text in 1-2 weeks, so that I can finalize version 02, which then hopefully can go to WGLC. | Information Refresh Time Option for DHCPv6 What do you think of this name? I think the problem with just "refresh time option" is that it sounds more like an option for refreshing time... |Abstract | | This document describes an option for specifying an upper bound for | how long a client should wait before refreshing information retrieved | from DHCP. It's useful for stateless DHCPv6 where there are no | addresses or other entities with lifetimes that can tell the client | when to contact the DHCP server to refresh its configuration. |1. Introduction | | DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 | hosts. However, many hosts will use stateless autoconfiguration as | specified in [RFC 2462] for address assignment, and use DHCPv6 only | for other configuration data. This other configuration data will | typically have no associated lifetime, hence there may be no | information telling a host when to refresh its DHCP configuration | data. | | This option may be useful in unstable environments where unexpected | changes are likely to occur, or for planned changes, including | renumbering where an administrator can gradually decrease the value | as the event nears. | | It may also be useful to allow the client to detect within an | appropriate amount of time when a specific service change has been | made, e.g. the addition of a new NTP server, or a change of address | of a DNS server within the local network. See [RENUMREQS] for | further details. |3. Information refresh time option definition | | The information refresh time option specifies an upper bound for how | long a client should wait before refreshing information retrieved | from DHCP. It's only used for replies to Information-request | messages. In other messages there will usually be other options that | indicate when the client should contact the server, e.g. addresses | with lifetimes. | | Note that it's only an upper bound. If the client has any reason to | make a DHCP request before the refresh time expires, it should | attempt to refresh all the data. | | There are a number of potential reasons for the client to contact the | server before the refresh time expires. One reason might be other | options that have some associated lifetime that is shorter than the | refresh time. Other reasons might be a new IPv6 prefix announced by | a router, or that a server becomes unreachable on the address learnt | from DHCP. The client may also determine that it needs to request | additional options. Do you think it's ok that client might update information if a server becomes unreachable? Say you learn DNS or NTP server address from DHCP, and at some point the resolver or NTP client determines that it can't reach the server. Would it then be ok to make the dhcp client request new data? An issue might be that if a server goes down, thousands of clients may try to update their DHCP config almost simultaneously... I'm only trying to give an example though, but is it a good one? | Note that this also means that it doesn't make sense to have | different refresh time options for different data, since when the | client has reason to refresh some of its data, it should also | refresh the remaining data. | | The expiry of the refresh time in itself does not in anyway mean that | the client should remove the data. The client should keep it's | current data while attempting to refresh it. The client is however | free to fall back to other mechanisms if it cannot refresh the data | within a reasonable amount of time. | | In some cases the client uses a default refresh time IRT_DEFAULT. | The recommended value for IRT_DEFAULT is 86400 (24 hours). The | client implementation should allow for this value to be configured. What do you think of 24 hours? I've got suggestions for 1, 6-12, at least 12 hours and more from you. |3.1. Client behaviour | | A client MUST include this option in the Option Request Option (ORO) | when sending Information-request messages to the DHCP server. A | client MUST NOT include this option in the ORO in any other messages. | | If the reply to an Information-request message does not contain this | option, the client MUST behave as if the option with value | IRT_DEFAULT was provided. | | A client MUST also use the default refresh time IRT_DEFAULT if it | receives the option with value less than 600. Do you agree with a minimum like this? It should make it harder to do bad things, and I don't see a use for <10 minutes. If <600, would you rather use 600 than IRT_DEFAULT? | If a client contacts the server to obtain new data or refresh some | existing data before the refresh time expires, then it SHOULD also | refresh all data covered by this option. | | When the client detects that the refresh time has expired, it SHOULD | try to update its configuration data by making a new DHCP request as | follows. | | Before making the request it MUST wait for a random amount of time | between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. | Note that this delay is in addition to the rules specified in [RFC | 3315]. | | Then it can make the DHCP request to update the configuration. The | message MUST be created and transmitted according to [RFC 3315]. For | an Information-request message it must be done according to the rules | for creation and transmission of Information-request messages in | section 18.1.5 of [RFC 3315]. We could perhaps say clearly that it must send Information-request. I think there's one thing we should discuss that is related to this. What if client at some point determines that it wants to request an address (switch to stateful mode). Then we should perhaps say that client should also refresh this data and forget the previous refresh time. What if it makes a request but does not get a reply with new data? Perhaps it should only forget refresh time when it gets new data, so that it can keep using it if not? |3.2. Server behaviour | | A server sending a reply to an Information-request message SHOULD | include this option if it's included in the ORO of the request. It Do you agree with SHOULD, or do you want MUST? My thinking is that server should allow the refresh time to be configured, and probably have IRT_DEFAULT as the default value (although some servers may prefer some other default, e.g. if made for us in a specific environment). Rather than sending the value IRT_DEFAULT it might just as well not include it. Do you think we should talk about this being configurable on the server and server default, or is it all pretty obvious and better left to the implementation? | MUST NOT be included if it's not in the ORO of the request. Is this ok? There's no harm in including it, but it's totally pointless since we require client to include it in ORO, so if not in the request, the client will ignore it. | When server sends a message that is not a reply to an Information- | request message, it MUST NOT include the option. It would be sufficient to say that it's only to be included if requested by client, since client MUST ONLY request it in Information-request messages. So this paragraph could be omitted. | The option value MUST be no less than 600. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 13:46:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04460; Wed, 25 Aug 2004 13:46:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01MB-00033U-MO; Wed, 25 Aug 2004 13:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01EG-00016f-1x for dhcwg@megatron.ietf.org; Wed, 25 Aug 2004 13:06:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01116 for ; Wed, 25 Aug 2004 13:06:24 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C01Ew-0005rL-Hb for dhcwg@ietf.org; Wed, 25 Aug 2004 13:07:15 -0400 Received: from ([172.16.57.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.3194576; Wed, 25 Aug 2004 13:04:01 -0400 Received: by oakexsmtp03.cable.comcast.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Aug 2004 13:05:20 -0400 Message-ID: From: "Woundy, Richard" To: "'Stig Venaas'" , dhcwg@ietf.org Subject: RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Wed, 25 Aug 2004 13:05:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >Do you think it's ok that client might update information if a server becomes unreachable? If the application server is down for network connectivity issues, and if the DHCPv6 server could only point to this application server which is down, and if there are now several hundred/thousand clients that want to reach the application server and cannot... Do you really want these several hundred/thousand clients to query the DHCPv6 server at once, to get no useful information??? -- rich -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Stig Venaas Sent: Wednesday, August 25, 2004 11:16 AM To: dhcwg@ietf.org Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 I've tried to update the text based on all the suggestions and comments received. I may still try to improve the language, but please read the text below and let me know if you have problems with what it says. Lines from the draft are prefixed by "|". I have some comments/questions inline. I'm hoping that we can come to agreement on the text in 1-2 weeks, so that I can finalize version 02, which then hopefully can go to WGLC. | Information Refresh Time Option for DHCPv6 What do you think of this name? I think the problem with just "refresh time option" is that it sounds more like an option for refreshing time... |Abstract | | This document describes an option for specifying an upper bound for | how long a client should wait before refreshing information retrieved | from DHCP. It's useful for stateless DHCPv6 where there are no | addresses or other entities with lifetimes that can tell the client | when to contact the DHCP server to refresh its configuration. |1. Introduction | | DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 | hosts. However, many hosts will use stateless autoconfiguration as | specified in [RFC 2462] for address assignment, and use DHCPv6 only | for other configuration data. This other configuration data will | typically have no associated lifetime, hence there may be no | information telling a host when to refresh its DHCP configuration | data. | | This option may be useful in unstable environments where unexpected | changes are likely to occur, or for planned changes, including | renumbering where an administrator can gradually decrease the value | as the event nears. | | It may also be useful to allow the client to detect within an | appropriate amount of time when a specific service change has been | made, e.g. the addition of a new NTP server, or a change of address | of a DNS server within the local network. See [RENUMREQS] for | further details. |3. Information refresh time option definition | | The information refresh time option specifies an upper bound for how | long a client should wait before refreshing information retrieved | from DHCP. It's only used for replies to Information-request | messages. In other messages there will usually be other options that | indicate when the client should contact the server, e.g. addresses | with lifetimes. | | Note that it's only an upper bound. If the client has any reason to | make a DHCP request before the refresh time expires, it should | attempt to refresh all the data. | | There are a number of potential reasons for the client to contact the | server before the refresh time expires. One reason might be other | options that have some associated lifetime that is shorter than the | refresh time. Other reasons might be a new IPv6 prefix announced by | a router, or that a server becomes unreachable on the address learnt | from DHCP. The client may also determine that it needs to request | additional options. Do you think it's ok that client might update information if a server becomes unreachable? Say you learn DNS or NTP server address from DHCP, and at some point the resolver or NTP client determines that it can't reach the server. Would it then be ok to make the dhcp client request new data? An issue might be that if a server goes down, thousands of clients may try to update their DHCP config almost simultaneously... I'm only trying to give an example though, but is it a good one? | Note that this also means that it doesn't make sense to have | different refresh time options for different data, since when the | client has reason to refresh some of its data, it should also refresh | the remaining data. | | The expiry of the refresh time in itself does not in anyway mean that | the client should remove the data. The client should keep it's | current data while attempting to refresh it. The client is however | free to fall back to other mechanisms if it cannot refresh the data | within a reasonable amount of time. | | In some cases the client uses a default refresh time IRT_DEFAULT. | The recommended value for IRT_DEFAULT is 86400 (24 hours). The | client implementation should allow for this value to be configured. What do you think of 24 hours? I've got suggestions for 1, 6-12, at least 12 hours and more from you. |3.1. Client behaviour | | A client MUST include this option in the Option Request Option (ORO) | when sending Information-request messages to the DHCP server. A | client MUST NOT include this option in the ORO in any other messages. | | If the reply to an Information-request message does not contain this | option, the client MUST behave as if the option with value | IRT_DEFAULT was provided. | | A client MUST also use the default refresh time IRT_DEFAULT if it | receives the option with value less than 600. Do you agree with a minimum like this? It should make it harder to do bad things, and I don't see a use for <10 minutes. If <600, would you rather use 600 than IRT_DEFAULT? | If a client contacts the server to obtain new data or refresh some | existing data before the refresh time expires, then it SHOULD also | refresh all data covered by this option. | | When the client detects that the refresh time has expired, it SHOULD | try to update its configuration data by making a new DHCP request as | follows. | | Before making the request it MUST wait for a random amount of time | between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. | Note that this delay is in addition to the rules specified in [RFC | 3315]. | | Then it can make the DHCP request to update the configuration. The | message MUST be created and transmitted according to [RFC 3315]. For | an Information-request message it must be done according to the rules | for creation and transmission of Information-request messages in | section 18.1.5 of [RFC 3315]. We could perhaps say clearly that it must send Information-request. I think there's one thing we should discuss that is related to this. What if client at some point determines that it wants to request an address (switch to stateful mode). Then we should perhaps say that client should also refresh this data and forget the previous refresh time. What if it makes a request but does not get a reply with new data? Perhaps it should only forget refresh time when it gets new data, so that it can keep using it if not? |3.2. Server behaviour | | A server sending a reply to an Information-request message SHOULD | include this option if it's included in the ORO of the request. It Do you agree with SHOULD, or do you want MUST? My thinking is that server should allow the refresh time to be configured, and probably have IRT_DEFAULT as the default value (although some servers may prefer some other default, e.g. if made for us in a specific environment). Rather than sending the value IRT_DEFAULT it might just as well not include it. Do you think we should talk about this being configurable on the server and server default, or is it all pretty obvious and better left to the implementation? | MUST NOT be included if it's not in the ORO of the request. Is this ok? There's no harm in including it, but it's totally pointless since we require client to include it in ORO, so if not in the request, the client will ignore it. | When server sends a message that is not a reply to an Information- | request message, it MUST NOT include the option. It would be sufficient to say that it's only to be included if requested by client, since client MUST ONLY request it in Information-request messages. So this paragraph could be omitted. | The option value MUST be no less than 600. 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 Aug 26 10:18:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03264; Thu, 26 Aug 2004 10:18:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0EWt-0007In-If; Thu, 26 Aug 2004 03:18:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0EJy-0005ES-BP for dhcwg@megatron.ietf.org; Thu, 26 Aug 2004 03:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12549 for ; Thu, 26 Aug 2004 03:05:12 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0EKh-0005wT-4r for dhcwg@ietf.org; Thu, 26 Aug 2004 03:06:08 -0400 Received: from suryapc (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I3100A4AKCH8V@mta0.huawei.com> for dhcwg@ietf.org; Thu, 26 Aug 2004 14:50:43 +0800 (CST) Date: Thu, 26 Aug 2004 12:27:32 +0500 From: Surya To: dhcwg@ietf.org Message-id: <00db01c48b3e$275176e0$5c04120a@suryapc> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: High X-Priority: 1 (Highest) X-MSMail-priority: High X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 1.3 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [dhcwg] DHCPv6 Source with Support. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: surya_pc@huawei.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1204140098==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1204140098== Content-type: multipart/alternative; boundary="Boundary_(ID_6RzbatvOiR6wkw0Cr1uAJw)" This is a multi-part message in MIME format. --Boundary_(ID_6RzbatvOiR6wkw0Cr1uAJw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi All, We wanted to purchase DHCPv6 server and Relay with Source code. We would like to know if such product along with source code & Support is available with you. Kindly provide us the information supporting to the product / features asap. Thanks & Regards, Surya. --Boundary_(ID_6RzbatvOiR6wkw0Cr1uAJw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 
Hi All,
 
We wanted to purchase DHCPv6 server and Relay with Source code. We would like to know if such product along with source code & Support is available with you. Kindly provide us the information supporting to the product / features asap. 
 
Thanks & Regards, 
Surya.

 

--Boundary_(ID_6RzbatvOiR6wkw0Cr1uAJw)-- --===============1204140098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1204140098==-- From dhcwg-bounces@ietf.org Thu Aug 26 11:20:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10345; Thu, 26 Aug 2004 11:20:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Le3-0002nZ-0q; Thu, 26 Aug 2004 10:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LSi-0007Z8-2o for dhcwg@megatron.ietf.org; Thu, 26 Aug 2004 10:42:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24884 for ; Thu, 26 Aug 2004 08:10:47 -0400 (EDT) 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.33) id 1C0J6X-0002gH-MP for dhcwg@ietf.org; Thu, 26 Aug 2004 08:11:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2004 05:15:28 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7QCABnV023292; Thu, 26 Aug 2004 05:10:11 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-161.cisco.com [10.86.240.161]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALC51210; Thu, 26 Aug 2004 08:10:09 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" , Subject: RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Thu, 26 Aug 2004 08:10:09 -0400 Organization: Cisco Message-ID: <000701c48b65$a23c6000$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040825151559.GJ5677@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Stig: Comments below, in line prefixed by "BV>". You don't document the format of the option? But, this is just a portion = of the text? - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Stig Venaas > Sent: Wednesday, August 25, 2004 11:16 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 >=20 >=20 > I've tried to update the text based on all the suggestions=20 > and comments received. I may still try to improve the=20 > language, but please read the text below and let me know if=20 > you have problems with what it says. Lines from the draft are=20 > prefixed by "|". I have some comments/questions inline. I'm=20 > hoping that we can come to agreement on the text in 1-2=20 > weeks, so that I can finalize version 02, which then=20 > hopefully can go to WGLC. >=20 >=20 > | Information Refresh Time Option for DHCPv6 >=20 > What do you think of this name? I think the problem with just=20 > "refresh time option" is that it sounds more like an option=20 > for refreshing time... >=20 > |Abstract > | > | This document describes an option for specifying an upper=20 > bound for =20 > | how long a client should wait before refreshing information=20 > retrieved =20 > | from DHCP. It's useful for stateless DHCPv6 where there are no =20 BV> "It is used with stateless DHCPv6 as there are no" > | addresses or other entities with lifetimes that can tell=20 > the client =20 > | when to contact the DHCP server to refresh its configuration. >=20 > |1. Introduction > | > | DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 =20 > | hosts. However, many hosts will use stateless=20 > autoconfiguration as =20 > | specified in [RFC 2462] for address assignment, and use=20 > DHCPv6 only =20 > | for other configuration data. This other configuration data will =20 BV> Add reference to [RFC 3736]? > | typically have no associated lifetime, hence there may be no =20 > | information telling a host when to refresh its DHCP configuration =20 > | data. > | > | This option may be useful in unstable environments where=20 > unexpected =20 > | changes are likely to occur, or for planned changes, including =20 > | renumbering where an administrator can gradually decrease=20 > the value =20 > | as the event nears. > | > | It may also be useful to allow the client to detect within an =20 > | appropriate amount of time when a specific service change has been =20 > | made, e.g. the addition of a new NTP server, or a change of=20 > address =20 > | of a DNS server within the local network. See [RENUMREQS] for =20 > | further details. >=20 > |3. Information refresh time option definition > | > | The information refresh time option specifies an upper=20 > bound for how =20 > | long a client should wait before refreshing information retrieved =20 > | from DHCP. It's only used for replies to Information-request =20 BV> "It is only used in Reply messages in response to = Information-Request" > | messages. In other messages there will usually be other=20 > options that =20 > | indicate when the client should contact the server, e.g. addresses =20 > | with lifetimes. > | > | Note that it's only an upper bound. If the client has any=20 > reason to =20 > | make a DHCP request before the refresh time expires, it should =20 > | attempt to refresh all the data. > | > | There are a number of potential reasons for the client to=20 > contact the =20 > | server before the refresh time expires. One reason might be other =20 > | options that have some associated lifetime that is shorter=20 > than the =20 > | refresh time. Other reasons might be a new IPv6 prefix=20 > announced by =20 > | a router, or that a server becomes unreachable on the=20 > address learnt =20 > | from DHCP. The client may also determine that it needs to request =20 > | additional options. >=20 > Do you think it's ok that client might update information if=20 > a server becomes unreachable? Say you learn DNS or NTP server=20 > address from DHCP, and at some point the resolver or NTP=20 > client determines that it can't reach the server. Would it=20 > then be ok to make the dhcp client request new data? An issue=20 > might be that if a server goes down, thousands of clients may=20 > try to update their DHCP config almost simultaneously... I'm=20 > only trying to give an example though, but is it a good one? NO. Like Rich, I think this would be an extremely bad idea. Let's remove = it. I'd replace the two above paragraphs with: The Information Refresh Time option's time is an upper bound as to = when the client SHOULD refresh its configuration information. A client MAY refresh this information before this time, such as if one or more prefixes for addresses in the configuration information expire. >=20 > | Note that this also means that it doesn't make sense to have =20 > | different refresh time options for different data, since when the =20 > | client has reason to refresh some of its data, it should=20 > also refresh=20 > | the remaining data. I'd reword this to simply state that there is ONE time for all = configuration data. > | > | The expiry of the refresh time in itself does not in=20 > anyway mean that =20 > | the client should remove the data. The client should keep it's =20 > | current data while attempting to refresh it. The client is=20 > however =20 > | free to fall back to other mechanisms if it cannot refresh=20 > the data =20 > | within a reasonable amount of time. > | > | In some cases the client uses a default refresh time IRT_DEFAULT. =20 > | The recommended value for IRT_DEFAULT is 86400 (24 hours). The =20 > | client implementation should allow for this value to be configured. >=20 > What do you think of 24 hours? I've got suggestions for 1,=20 > 6-12, at least 12 hours and more from you. I like 24 hours. >=20 > |3.1. Client behaviour > | > | A client MUST include this option in the Option Request=20 > Option (ORO) =20 > | when sending Information-request messages to the DHCP server. A =20 > | client MUST NOT include this option in the ORO in any other=20 > messages. Perhaps: "If a client supports this option, it MUST ..." > | > | If the reply to an Information-request message does not=20 > contain this =20 > | option, the client MUST behave as if the option with value =20 > | IRT_DEFAULT was provided. > | > | A client MUST also use the default refresh time IRT_DEFAULT if it =20 > | receives the option with value less than 600. >=20 > Do you agree with a minimum like this? It should make it=20 > harder to do bad things, and I don't see a use for <10=20 > minutes. If <600, would you rather use 600 than IRT_DEFAULT? As I suggested it, I like it. Perhaps we should specify IRT_MINIMUM as a parameter? >=20 > | If a client contacts the server to obtain new data or=20 > refresh some =20 > | existing data before the refresh time expires, then it SHOULD also =20 > | refresh all data covered by this option. > | > | When the client detects that the refresh time has expired,=20 > it SHOULD =20 > | try to update its configuration data by making a new DHCP=20 > request as =20 > | follows. > | > | Before making the request it MUST wait for a random amount=20 > of time =20 > | between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in=20 > [RFC 3315]. =20 > | Note that this delay is in addition to the rules specified in [RFC =20 > | 3315]. > | > | Then it can make the DHCP request to update the=20 > configuration. The =20 > | message MUST be created and transmitted according to [RFC=20 > 3315]. For =20 > | an Information-request message it must be done according to=20 > the rules =20 > | for creation and transmission of Information-request messages in =20 > | section 18.1.5 of [RFC 3315]. >=20 > We could perhaps say clearly that it must send Information-request. >=20 > I think there's one thing we should discuss that is related=20 > to this. What if client at some point determines that it=20 > wants to request an address (switch to stateful mode). Then=20 > we should perhaps say that client should also refresh this=20 > data and forget the previous refresh time. What if it makes a=20 > request but does not get a reply with new data? Perhaps it=20 > should only forget refresh time when it gets new data, so=20 > that it can keep using it if not? Let's not mention this. Clients should always request this other conf. = info. >=20 > |3.2. Server behaviour > | > | A server sending a reply to an Information-request message SHOULD =20 > | include this option if it's included in the ORO of the request. It BV> "if it is". >=20 > Do you agree with SHOULD, or do you want MUST? My thinking is=20 > that server should allow the refresh time to be configured,=20 > and probably have IRT_DEFAULT as the default value (although=20 > some servers may prefer some other default, e.g. if made for=20 > us in a specific environment). Rather than sending the value=20 > IRT_DEFAULT it might just as well not include it. BV> If configured in the server, the server MUST return it (if = requested). I do not think the server should treat this option specially - such as = supply a default if not configured. >=20 > Do you think we should talk about this being configurable on=20 > the server and server default, or is it all pretty obvious=20 > and better left to the implementation? >=20 BV> Pretty obvious. > | MUST NOT be included if it's not in the ORO of the request. >=20 > Is this ok? There's no harm in including it, but it's totally=20 > pointless since we require client to include it in ORO, so if=20 > not in the request, the client will ignore it. BV> No, drop it. A server is always free to include any other options it wants. If a client doesn't support it, it will ignore it. >=20 > | When server sends a message that is not a reply to an=20 > Information- =20 > | request message, it MUST NOT include the option. >=20 > It would be sufficient to say that it's only to be included=20 > if requested by client, since client MUST ONLY request it in=20 > Information-request messages. So this paragraph could be omitted. BV> I'd drop it. If a client were to include this option in an ORO for a non-Information-Request message, and it was configured in the server, = the server might return it (again, want to avoid special code in the server) = and I think that is OK. The client is wrong but so what - what the client = might do with this time is unknown but since it is broken, do we really care? = Fix the client. >=20 > | The option value MUST be no less than 600. BV> I'd leave this to the client. >=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 Aug 27 01:54:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15920; Fri, 27 Aug 2004 01:54:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZaD-0007B4-Cy; Fri, 27 Aug 2004 01:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZZ9-0006rJ-CX for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 01:46:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15662 for ; Fri, 27 Aug 2004 01:46:21 -0400 (EDT) Received: from 203-69-237-46.hinet-ip.hinet.net ([203.69.237.46] helo=delta.noi.kre.to) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ZaB-0000mT-Mq for dhcwg@ietf.org; Fri, 27 Aug 2004 01:47:30 -0400 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7R5j29O000810; Fri, 27 Aug 2004 12:45:06 +0700 (ICT) From: Robert Elz To: "Bernie Volz" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) In-Reply-To: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> References: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 2004 12:45:02 +0700 Message-ID: <29651.1093585502@munnari.OZ.AU> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com, "'Stig Venaas'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Date: Tue, 24 Aug 2004 21:00:45 -0400 From: "Bernie Volz" Message-ID: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> | I'd vote for "Refresh Time Option". I have no problem renaming this The name of the option isn't really the point. Jinmei has a valid point, but didn't manage to express the real issue perhaps as clearly as should have been done. The issue isn't really "what happens when the lifetime expires" (whatever you call it), the issue is "what happens when the DHCP server doesn't give us some information that was given to us before" ? You're mostly all thinking (it seems) of the case where the DHCP server doesn't reply at all to a later request for information - and so no new data is provided. The other case, where the dhcp server does reply, and supplies new information. We all know what to do in that case. But those aren't the only two cases - the problem case is what happens when the (a) DHCP server does reply, but only supplies values for some of the options that an earlier DHCP response had supplied. That is, suppose I ask for NTP servers and DNS servers. When I boot I get told fe80::99 for NTP, and fe80::7 for DNS. Then later, I ask again, and get told 2001:1234:5678::16 for DNS, but get no NTP server addresses supplied at all. What is the client expected to do in that case? It seems reasonably clear (to me anyway) that the likely cause of this kind of change, is that the client is a portable device, that has been moved from one location to another, and is now talking to a different DHCP server than it was before (though entirely possibly both servers migh just happen to have been configured at fe80::9 on their respective LANs). Should the client just keep on using the (probably now bogus) NTP server address, or should it just give up on NTP, given the local lan most likely has no available server? Does it make a difference if the previous "lifetime" has or has not expired? Or for that matter, whether or not there was ever a lifetime option, or whether or not the client requested it (and knows anything aboutthis new option) ? Once you work out the right answer to that problem, it is a minor issue to extend that answer to the case where no answers at all are returned. kre ps: notice here I am not suggesting what the answer should be. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 02:20:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01197; Fri, 27 Aug 2004 02:20:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZyN-0007RN-SF; Fri, 27 Aug 2004 02:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZwD-0006F4-KH for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 02:10:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26411 for ; Fri, 27 Aug 2004 02:10:12 -0400 (EDT) Received: from 203-69-237-46.hinet-ip.hinet.net ([203.69.237.46] helo=delta.noi.kre.to) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ZxH-00019w-Fw for dhcwg@ietf.org; Fri, 27 Aug 2004 02:11:21 -0400 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7R68W9O011614; Fri, 27 Aug 2004 13:08:33 +0700 (ICT) From: Robert Elz To: "Bernie Volz" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 2004 13:08:32 +0700 Message-ID: <6493.1093586912@munnari.OZ.AU> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, "'Stig Venaas'" , jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Date: Fri, 20 Aug 2004 08:44:14 -0400 From: "Bernie Volz" Message-ID: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> | I'm OK to restricting the Lifetime Option to replies to | Information-Request's. | | The client MUST ignore a Lifetime Option that is in any message other than a | REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime | Option number in an ORO except when sending an INFORMATION-REQUEST message. | | The server MUST NOT include the Lifetime Option in any message other than a | REPLY to an INFORMATION-REQUEST. I've been reading all of the messages on this topic (catching up) and I haven't managed to find a reason why anyone would want to add this kind of restriction, I just don't see the need. You seem to all be imagining that things have to get much more complex for the clients if they get two timer values, and they're different. But that's nonsense. All of these timers are just upper bounds - a client that wants to be simple just wants a single timer. If one option says "the upper bound is 86400 seconds" and another says "the upper bound is 43200 seconds", then to the client, it just tries again, for all the info, before the 43200 second timer expires. This isn't complex, it is trivial. On the other hand, if the client doesn't need to be quite that simple, then I see no compelling reason to require it to be so. In particular, and especially given we're talking about IPv6, I see no reason why a client shouldn't use very long lease times (well, comparatively long - in IPv4 I've seen values counted in years - that's absurd, but values of several weeks for address lifetime should be reasonable). If there's no prospect that the prefixes are going to change anytime soon, there's no reason that an IPv6 node shouldn't be able to keep using its address for a very long time, even if the DHCP server is down for an extended period (and that's what the lease timers are all about really - no-one disputes but that addresses stop being used when their lifetime expires). On the other hand, we may want to be able to shift which hosts run various servers with much time lag, so the "other option lifetime" (or whatever it ends up being called) might want to be quite a bit smaller (maybe measured in hours, or a day or so). A simple client will simply refresh everything when the shorter timer expires. A complex one might prefer to just use info requests when the shorter info timer expires, and only do the full dhcp protocol when the addresses actually expire - aside from anything else, this allows dhcp-lite servers to respond, where only a full duchv6 server can handle address requests. Why would anyone really want to forbid this? That's all the proposed language is doing, nothing really gets any simpler (in a simple client now instead of just taking the lower timer value, it instead has to know to ignore this particular option if it happens to occur in that particular message type - which I think is a rather unusual case). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 02:27:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02060; Fri, 27 Aug 2004 02:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0aBH-0005ov-Bb; Fri, 27 Aug 2004 02:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0a9T-0004on-Im for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 02:23:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01754 for ; Fri, 27 Aug 2004 02:23:53 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0aAY-0001RI-SV for dhcwg@ietf.org; Fri, 27 Aug 2004 02:25:03 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7R6NMOK013396; Fri, 27 Aug 2004 08:23:22 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7R6NLh5015094; Fri, 27 Aug 2004 08:23:21 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 27 Aug 2004 08:23:21 +0200 From: Stig Venaas To: Robert Elz Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) Message-ID: <20040827062321.GA15052@sverresborg.uninett.no> References: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> <29651.1093585502@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29651.1093585502@munnari.OZ.AU> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 27, 2004 at 12:45:02PM +0700, Robert Elz wrote: > Date: Tue, 24 Aug 2004 21:00:45 -0400 > From: "Bernie Volz" > Message-ID: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> > > | I'd vote for "Refresh Time Option". I have no problem renaming this > > The name of the option isn't really the point. Jinmei has a valid point, > but didn't manage to express the real issue perhaps as clearly as should > have been done. > > The issue isn't really "what happens when the lifetime expires" (whatever > you call it), the issue is "what happens when the DHCP server doesn't give > us some information that was given to us before" ? > > You're mostly all thinking (it seems) of the case where the DHCP server > doesn't reply at all to a later request for information - and so no new > data is provided. > > The other case, where the dhcp server does reply, and supplies new information. > We all know what to do in that case. > > But those aren't the only two cases - the problem case is what happens when > the (a) DHCP server does reply, but only supplies values for some of the > options that an earlier DHCP response had supplied. > > That is, suppose I ask for NTP servers and DNS servers. When I boot > I get told fe80::99 for NTP, and fe80::7 for DNS. Then later, I ask > again, and get told 2001:1234:5678::16 for DNS, but get no NTP server > addresses supplied at all. > > What is the client expected to do in that case? It seems reasonably clear > (to me anyway) that the likely cause of this kind of change, is that the > client is a portable device, that has been moved from one location to > another, and is now talking to a different DHCP server than it was before > (though entirely possibly both servers migh just happen to have been > configured at fe80::9 on their respective LANs). > > Should the client just keep on using the (probably now bogus) NTP server > address, or should it just give up on NTP, given the local lan most > likely has no available server? Does it make a difference if the > previous "lifetime" has or has not expired? Or for that matter, whether > or not there was ever a lifetime option, or whether or not the client > requested it (and knows anything aboutthis new option) ? Thanks for making this clear. We just had some discussion on this, but the problem was perhaps not clearly stated. And this is one of the things I tried to ask. What would you do if this happened without this option. As you said, this is a more generic problem, and it makes me wonder whether people already have thought about this. > Once you work out the right answer to that problem, it is a minor issue to > extend that answer to the case where no answers at all are returned. Is there a theoretical possibility that you get a response, but without any options? That should possibly be treated differently from not getting any reply at all. > kre > > ps: notice here I am not suggesting what the answer should be. If you get a response from a server, and later a new from the same server but with some options missing, then I believe the administrator must have removed the it on purpose and the old information is not valid. However, this is not so clear if you get a reply from a new server. If you're still in the same site, then I think situation is pretty much like above. But if the client has moved to a new site, the old information might be valid, but not necessarily. E.g. if I learn an NTP server at home, I might wish to keep using it from a new location, even if the administrator in that new location doesn't care about NTP and hasn't configured anything. Whether I should continue using the one at home really depends on policy. The access to the NTP server might for instance be blocked in a firewall deployed in/around my home site or the site I'm now visiting. I'm not sure if the answer to these issues need to be described in the draft since it's a more generic issue. OTOH this draft might be the most obvious place we have for now. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 02:59:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04327; Fri, 27 Aug 2004 02:59:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ad6-0002i6-8z; Fri, 27 Aug 2004 02:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0abj-0002QV-Up for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 02:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03994 for ; Fri, 27 Aug 2004 02:53:05 -0400 (EDT) Received: from 203-69-237-46.hinet-ip.hinet.net ([203.69.237.46] helo=delta.noi.kre.to) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0acn-0001zk-TB for dhcwg@ietf.org; Fri, 27 Aug 2004 02:54:15 -0400 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7R6qn9O002427; Fri, 27 Aug 2004 13:52:52 +0700 (ICT) From: Robert Elz To: Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) In-Reply-To: <20040827062321.GA15052@sverresborg.uninett.no> References: <20040827062321.GA15052@sverresborg.uninett.no> <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> <29651.1093585502@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 2004 13:52:49 +0700 Message-ID: <77.1093589569@munnari.OZ.AU> 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Date: Fri, 27 Aug 2004 08:23:21 +0200 From: Stig Venaas Message-ID: <20040827062321.GA15052@sverresborg.uninett.no> | I'm not sure if the answer to these issues need to be described in | the draft since it's a more generic issue. OTOH this draft might be | the most obvious place we have for now. Yes, it is a much bigger issue than just providing a mechanism for specifying when a new info request should be attempted. But it is when we specify that that the problem becomes obvious, and we need to have a solution - until now (including in IPv4) we mostly just pretended that none of this ever happened, and once learned, all of this information was static forever (hence, DNS "servers" (back end resolvers really) go in /etc/resolv.conf - that gets updated when the info changes, but applications know nothing of that, and simply keep on using the old information forever). All this is something of a quagmire - but is something that needs to be addressed, and ought to be addressed along with this new option (if not necessarily in the same document). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 04:36:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09737; Fri, 27 Aug 2004 04:36:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0cBp-00033G-Pu; Fri, 27 Aug 2004 04:34:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0cBX-0002uC-66 for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 04:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09596 for ; Fri, 27 Aug 2004 04:34:08 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0cCc-0003tI-Om for dhcwg@ietf.org; Fri, 27 Aug 2004 04:35:20 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i7R8Y7gg012015 for ; Fri, 27 Aug 2004 09:34:07 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA18370 for ; Fri, 27 Aug 2004 09:34:06 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i7R8Y6a27338 for dhcwg@ietf.org; Fri, 27 Aug 2004 09:34:06 +0100 Date: Fri, 27 Aug 2004 09:34:06 +0100 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Message-ID: <20040827083406.GA26829@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <20040825151559.GJ5677@sverresborg.uninett.no> <000701c48b65$a23c6000$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c48b65$a23c6000$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Thu, Aug 26, 2004 at 08:10:09AM -0400, Bernie Volz wrote: > > > > Do you think it's ok that client might update information if > > a server becomes unreachable? Say you learn DNS or NTP server > > address from DHCP, and at some point the resolver or NTP > > client determines that it can't reach the server. Would it > > then be ok to make the dhcp client request new data? An issue > > might be that if a server goes down, thousands of clients may > > try to update their DHCP config almost simultaneously... I'm > > only trying to give an example though, but is it a good one? > > NO. Like Rich, I think this would be an extremely bad idea. Let's remove it. > > I'd replace the two above paragraphs with: > > The Information Refresh Time option's time is an upper bound as to when > the client SHOULD refresh its configuration information. A client MAY > refresh this information before this time, such as if one or more > prefixes for addresses in the configuration information expire. That sounds fine to me. > > | Note that this also means that it doesn't make sense to have > > | different refresh time options for different data, since when the > > | client has reason to refresh some of its data, it should > > also refresh > > | the remaining data. > > I'd reword this to simply state that there is ONE time for all configuration > data. Also fine by me. Less is more :) > > | In some cases the client uses a default refresh time IRT_DEFAULT. > > | The recommended value for IRT_DEFAULT is 86400 (24 hours). The > > | client implementation should allow for this value to be configured. > > > > What do you think of 24 hours? I've got suggestions for 1, > > 6-12, at least 12 hours and more from you. > > I like 24 hours. The value will depend on the environment. I think if the admin knows the environment is one liable to be changed, they will make active use of this timer, if not, then it'll be a typical (relatively) static environment in which case 24 hours would be ample. In the event of a major change, the admin can ramp it down. > > Do you agree with a minimum like this? It should make it > > harder to do bad things, and I don't see a use for <10 > > minutes. If <600, would you rather use 600 than IRT_DEFAULT? > > As I suggested it, I like it. Perhaps we should specify IRT_MINIMUM as a > parameter? I think this is an interesting suggestion. Again, it depends on the environment. If it's a renumbering event, and a document like Fred Baker's without-a-flag-day draft is followed, the minimum value can certainly be higher than 10 minutes. One would assume in that type of renumbering environment the old and new prefixes coexist for some time. If a DNS or NTP server is being turned off/phased out, then the replacement should be made available in advance. The awkward case is where there is a sudden transition between (DNS, NTP, etc) servers or networks, but these are I believe typically user, not administrator, driven. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 07:01:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19257; Fri, 27 Aug 2004 07:01:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eHU-0002t0-O6; Fri, 27 Aug 2004 06:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eFd-0002U6-4u for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 06:46:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18257 for ; Fri, 27 Aug 2004 06:46:29 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0eGi-0006UR-37 for dhcwg@ietf.org; Fri, 27 Aug 2004 06:47:43 -0400 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 11:46:42 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 11:46:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Fri, 27 Aug 2004 11:46:41 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A7009943EFD@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 thread-index: AcSKvccrDrJPNfWiR9CectTdxbkgewBZNLDw To: X-OriginalArrivalTime: 27 Aug 2004 10:46:41.0973 (UTC) FILETIME=[23737650:01C48C23] X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Stig, > I've tried to update the text based on all the suggestions and > comments received. I may still try to improve the language, but > please read the text below and let me know if you have problems > with what it says. Lines from the draft are prefixed by "|". I > have some comments/questions inline. I'm hoping that we can come > to agreement on the text in 1-2 weeks, so that I can finalize > version 02, which then hopefully can go to WGLC. >=20 >=20 >> Information Refresh Time Option for DHCPv6 >=20 > What do you think of this name? I think the problem with just > "refresh time option" is that it sounds more like an option for > refreshing time...=20 I think if you hyphenate Refresh-Time then the meaning is clearer. Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 07:43:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21682; Fri, 27 Aug 2004 07:43:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ezW-0002ih-2C; Fri, 27 Aug 2004 07:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eyn-0002YX-VK for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 07:33:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21088 for ; Fri, 27 Aug 2004 07:33:12 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ezv-0007LU-Ar for dhcwg@ietf.org; Fri, 27 Aug 2004 07:34:24 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7RBWdOK021455; Fri, 27 Aug 2004 13:32:39 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7RBWdhu015838; Fri, 27 Aug 2004 13:32:39 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 27 Aug 2004 13:32:39 +0200 From: Stig Venaas To: matthew.ford@bt.com Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Message-ID: <20040827113239.GH15420@sverresborg.uninett.no> References: <0AAF93247C75E3408638B965DEE11A7009943EFD@i2km41-ukdy.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0AAF93247C75E3408638B965DEE11A7009943EFD@i2km41-ukdy.domain1.systemhost.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 27, 2004 at 11:46:41AM +0100, matthew.ford@bt.com wrote: > Hi Stig, > > > I've tried to update the text based on all the suggestions and > > comments received. I may still try to improve the language, but > > please read the text below and let me know if you have problems > > with what it says. Lines from the draft are prefixed by "|". I > > have some comments/questions inline. I'm hoping that we can come > > to agreement on the text in 1-2 weeks, so that I can finalize > > version 02, which then hopefully can go to WGLC. > > > > > >> Information Refresh Time Option for DHCPv6 > > > > What do you think of this name? I think the problem with just > > "refresh time option" is that it sounds more like an option for > > refreshing time... > > I think if you hyphenate Refresh-Time then the meaning is clearer. Yes, I agree, and I was about to do that, until I checked with my local linguist friend. At least he claimed it was no good... Thanks, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 07:49:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21985; Fri, 27 Aug 2004 07:49:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0fD8-000529-1f; Fri, 27 Aug 2004 07:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0f8M-00045W-Fz for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 07:43:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21697 for ; Fri, 27 Aug 2004 07:43:04 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0f9R-0007Vf-Nt for dhcwg@ietf.org; Fri, 27 Aug 2004 07:44:17 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 12:43:11 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 12:43:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Fri, 27 Aug 2004 12:43:10 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A7009943F85@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 thread-index: AcSMKasU4VtOYt5TS0WaX7GCzKuM1QAAWK1w To: X-OriginalArrivalTime: 27 Aug 2004 11:43:11.0175 (UTC) FILETIME=[0792A570:01C48C2B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable On 27 August 2004 12:33, Stig Venaas wrote: > On Fri, Aug 27, 2004 at 11:46:41AM +0100, matthew.ford@bt.com wrote: >> I think if you hyphenate Refresh-Time then the meaning is clearer. >=20 > Yes, I agree, and I was about to do that, until I checked > with my local > linguist friend. At least he claimed it was no good... Nonsense - this is precisely what hyphens are for! Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 09:13:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27355; Fri, 27 Aug 2004 09:13:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gRK-0003WG-BM; Fri, 27 Aug 2004 09:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gFH-000136-6f for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 08:54:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26488 for ; Fri, 27 Aug 2004 08:54:17 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gGN-0000bj-71 for dhcwg@ietf.org; Fri, 27 Aug 2004 08:55:30 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7RCsCkC007802; Fri, 27 Aug 2004 07:54:12 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7RCsCY01808; Fri, 27 Aug 2004 08:54:12 -0400 (EDT) From: Joe Quanaim To: Stig Venaas , dhcwg@ietf.org Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Fri, 27 Aug 2004 08:54:09 -0400 User-Agent: KMail/1.5.4 References: <20040825151559.GJ5677@sverresborg.uninett.no> In-Reply-To: <20040825151559.GJ5677@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408270854.10485.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > | A client MUST also use the default refresh time IRT_DEFAULT if it > | receives the option with value less than 600. > > Do you agree with a minimum like this? It should make it harder to > do bad things, and I don't see a use for <10 minutes. If <600, > would you rather use 600 than IRT_DEFAULT? I think a minimum is a good idea, but it probably should not be reset to 24 hours. That's probably not what an admin intended by setting the value that low. Also, are 0 or 0xffffffff a special case like elsewhere in dhcpv6? I am not sure it's necessary; I am just bringing up the point. Thanks, Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 09:46:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29395; Fri, 27 Aug 2004 09:46:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gy1-0001MB-Ot; Fri, 27 Aug 2004 09:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gok-0008O7-0c for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 09:30:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28406 for ; Fri, 27 Aug 2004 09:30:55 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gpq-0001Hw-8y for dhcwg@ietf.org; Fri, 27 Aug 2004 09:32:09 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i7RDUIEG002450; Fri, 27 Aug 2004 08:30:19 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7RDUIY16252; Fri, 27 Aug 2004 09:30:18 -0400 (EDT) From: Joe Quanaim To: Robert Elz , Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) Date: Fri, 27 Aug 2004 09:29:46 -0400 User-Agent: KMail/1.5.4 References: <20040827062321.GA15052@sverresborg.uninett.no> <29651.1093585502@munnari.OZ.AU> <77.1093589569@munnari.OZ.AU> In-Reply-To: <77.1093589569@munnari.OZ.AU> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408270928.58762.jdq@lucent.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Fri, 27 Aug 2004 08:23:21 +0200 > From: Stig Venaas > Message-ID: <20040827062321.GA15052@sverresborg.uninett.no> > > | I'm not sure if the answer to these issues need to be described in > | the draft since it's a more generic issue. OTOH this draft might be > | the most obvious place we have for now. > > Yes, it is a much bigger issue than just providing a mechanism for > specifying when a new info request should be attempted. > > But it is when we specify that that the problem becomes obvious, and > we need to have a solution - until now (including in IPv4) we mostly > just pretended that none of this ever happened, and once learned, all > of this information was static forever (hence, DNS "servers" (back end > resolvers really) go in /etc/resolv.conf - that gets updated when the > info changes, but applications know nothing of that, and simply keep on > using the old information forever). > > All this is something of a quagmire - but is something that needs to be > addressed, and ought to be addressed along with this new option (if not > necessarily in the same document). I agree that this is an issue, but I don't think it's something this document should address. It's a larger part of the dhcp specification, and the example you gave could happen in stateful configuration as well. For the example involving dns and this option, I read the draft as such: when the option expires, don't dismiss the configured dns data. Request new information. When new information is received, replace the existing data with the newly obtained. This prevents the client from being left without dns while making an attempt to be current. Also, if a server returns an empty set of dns servers, that is what the client should use. It doesn't make much sense, but misconfigured dhcp servers aren't something a client should be programmed to handle. Generalizing this issue is not simple. How does a dhcp client update the ntp configuration? And why does it? The ntp configuration could be pointing to a server reachable from multiple networks. This seems like local policy. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 10:33:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03581; Fri, 27 Aug 2004 10:33:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0hcY-0002ku-4K; Fri, 27 Aug 2004 10:22:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0hbF-0000CQ-3I; Fri, 27 Aug 2004 10:21:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02511; Fri, 27 Aug 2004 10:21:01 -0400 (EDT) Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0hcK-0002A1-Gv; Fri, 27 Aug 2004 10:22:16 -0400 Received: from keshavaak (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I33008CVYON0Y@mta1.huawei.com>; Fri, 27 Aug 2004 21:55:37 +0800 (CST) Date: Fri, 27 Aug 2004 19:39:52 +0530 From: Keshava To: dhcwg@ietf.org, ipv6@ietf.org Message-id: <001f01c48c3f$86a44f80$1604120a@keshavaak> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.4 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: keshavaak@huawei.com, maoshx@huawei.com Subject: [dhcwg] dhcp6 verndor class option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Keshava List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0775208248==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0775208248== Content-type: multipart/alternative; boundary="Boundary_(ID_6hDmIfeoCuAc3QwOZr/rDg)" This is a multi-part message in MIME format. --Boundary_(ID_6hDmIfeoCuAc3QwOZr/rDg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Can you please clarify in he RFC 3315 (DHCP6) "Appearance of Options in Message Types" section mentions that the dhcp6 relay should support vendor class option. But in the message processing in the "Section 22.16 Vendor Class Option" does not mention any thing about this for relay . It only mentions about how the client should process this. Can some one please clarify this what should be done for dhcp6 relay ? regards, keshava --Boundary_(ID_6hDmIfeoCuAc3QwOZr/rDg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
    Can you please clarify  in he RFC 3315 (DHCP6)
 
   "Appearance of Options in Message Types" section mentions that the dhcp6 relay should support
     vendor class option.
  
    But in the message processing in the "Section 22.16 Vendor Class Option"  does not mention any
    thing about this for relay . It only mentions about how the client should process this.
 
     Can some one please clarify this  what should be done for dhcp6 relay ?
 
 
regards,
keshava
--Boundary_(ID_6hDmIfeoCuAc3QwOZr/rDg)-- --===============0775208248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0775208248==-- From dhcwg-bounces@ietf.org Fri Aug 27 14:45:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24051; Fri, 27 Aug 2004 14:45:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0lf2-0000SK-Ov; Fri, 27 Aug 2004 14:41:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0lWm-0006YE-7B for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 14:32:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22073 for ; Fri, 27 Aug 2004 14:32:42 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0lXx-0007no-5m for dhcwg@ietf.org; Fri, 27 Aug 2004 14:33:58 -0400 Received: from [10.222.34.118] (m815f36d0.tmodns.net [208.54.95.129]) by toccata.fugue.com (Postfix) with ESMTP id 932E51B2003 for ; Fri, 27 Aug 2004 13:31:49 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200408270928.58762.jdq@lucent.com> References: <20040827062321.GA15052@sverresborg.uninett.no> <29651.1093585502@munnari.OZ.AU> <77.1093589569@munnari.OZ.AU> <200408270928.58762.jdq@lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B6727F5-F857-11D8-A7B9-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) Date: Fri, 27 Aug 2004 13:32:42 -0500 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 8:29 AM, Joe Quanaim wrote: > For the example involving dns and this option, I read the draft as > such: when > the option expires, don't dismiss the configured dns data. Request new > information. When new information is received, replace the existing > data > with the newly obtained. This prevents the client from being left > without > dns while making an attempt to be current. Also, if a server returns > an > empty set of dns servers, that is what the client should use. It > doesn't > make much sense, but misconfigured dhcp servers aren't something a > client > should be programmed to handle. I agree that this is what the client should do. If this isn't clear to kre from reading it, then perhaps we need to make it clearer, but I certainly agree that this is the behavior that we want to specify. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 23:41:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03228; Fri, 27 Aug 2004 23:41:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0twy-0006Vx-Ky; Fri, 27 Aug 2004 23:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0tuE-0005zh-VJ for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 23:29:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02630 for ; Fri, 27 Aug 2004 23:29:26 -0400 (EDT) Received: from smtp1.agni.com ([202.53.160.4] helo=mx.agni.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0tvP-0003U6-7F for dhcwg@ietf.org; Fri, 27 Aug 2004 23:30:48 -0400 Received: from inspbg.com ([202.53.160.107] helo=server.inspbg) by mx.agni.com with esmtp (Exim 4.12) id 1C0tt4-0005SY-00 for dhcwg@ietf.org; Sat, 28 Aug 2004 09:28:24 +0600 Received: by SERVER with Internet Mail Service (5.5.2448.0) id ; Sat, 28 Aug 2004 09:28:26 +0600 Message-ID: From: "Dhaka . Razzak" To: "'dhcwg@ietf.org'" Date: Sat, 28 Aug 2004 09:28:24 +0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MailScanner-Information: Scanned by agni's email virus scanner at smtp1 X-MailScanner: Clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6, BAYES_00 -4.90) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Subject: [dhcwg] Re: Contents of dhcwg digest... 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org -----Original Message----- From: dhcwg-request@ietf.org [SMTP:dhcwg-request@ietf.org] Sent: Friday, August 27, 2004 10:12 PM To: dhcwg@ietf.org Subject: dhcwg Digest, Vol 4, Issue 38 Send dhcwg mailing list submissions to dhcwg@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org You can reach the person managing the list at dhcwg-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." Today's Topics: 1. Re: Attempt at text for draft-ietf-dhc-lifetime-02 (Joe Quanaim) 2. Re: behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) (Joe Quanaim) 3. dhcp6 verndor class option (Keshava) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 Aug 2004 08:54:09 -0400 From: Joe Quanaim Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 To: Stig Venaas , dhcwg@ietf.org Message-ID: <200408270854.10485.jdq@lucent.com> Content-Type: text/plain; charset="iso-8859-1" Stig Venaas wrote: > | A client MUST also use the default refresh time IRT_DEFAULT if it > | receives the option with value less than 600. > > Do you agree with a minimum like this? It should make it harder to > do bad things, and I don't see a use for <10 minutes. If <600, > would you rather use 600 than IRT_DEFAULT? I think a minimum is a good idea, but it probably should not be reset to 24 hours. That's probably not what an admin intended by setting the value that low. Also, are 0 or 0xffffffff a special case like elsewhere in dhcpv6? I am not sure it's necessary; I am just bringing up the point. Thanks, Joe Quanaim. ------------------------------ Message: 2 Date: Fri, 27 Aug 2004 09:29:46 -0400 From: Joe Quanaim Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) To: Robert Elz , Stig Venaas Cc: dhcwg@ietf.org Message-ID: <200408270928.58762.jdq@lucent.com> Content-Type: text/plain; charset="iso-8859-1" Robert Elz wrote: > Date: Fri, 27 Aug 2004 08:23:21 +0200 > From: Stig Venaas > Message-ID: <20040827062321.GA15052@sverresborg.uninett.no> > > | I'm not sure if the answer to these issues need to be described in > | the draft since it's a more generic issue. OTOH this draft might be > | the most obvious place we have for now. > > Yes, it is a much bigger issue than just providing a mechanism for > specifying when a new info request should be attempted. > > But it is when we specify that that the problem becomes obvious, and > we need to have a solution - until now (including in IPv4) we mostly > just pretended that none of this ever happened, and once learned, all > of this information was static forever (hence, DNS "servers" (back end > resolvers really) go in /etc/resolv.conf - that gets updated when the > info changes, but applications know nothing of that, and simply keep on > using the old information forever). > > All this is something of a quagmire - but is something that needs to be > addressed, and ought to be addressed along with this new option (if not > necessarily in the same document). I agree that this is an issue, but I don't think it's something this document should address. It's a larger part of the dhcp specification, and the example you gave could happen in stateful configuration as well. For the example involving dns and this option, I read the draft as such: when the option expires, don't dismiss the configured dns data. Request new information. When new information is received, replace the existing data with the newly obtained. This prevents the client from being left without dns while making an attempt to be current. Also, if a server returns an empty set of dns servers, that is what the client should use. It doesn't make much sense, but misconfigured dhcp servers aren't something a client should be programmed to handle. Generalizing this issue is not simple. How does a dhcp client update the ntp configuration? And why does it? The ntp configuration could be pointing to a server reachable from multiple networks. This seems like local policy. Joe Quanaim. ------------------------------ Message: 3 Date: Fri, 27 Aug 2004 19:39:52 +0530 From: Keshava Subject: [dhcwg] dhcp6 verndor class option To: dhcwg@ietf.org, ipv6@ietf.org Cc: keshavaak@huawei.com, maoshx@huawei.com Message-ID: <001f01c48c3f$86a44f80$1604120a@keshavaak> Content-Type: text/plain; charset="iso-8859-1" Hi, Can you please clarify in he RFC 3315 (DHCP6) "Appearance of Options in Message Types" section mentions that the dhcp6 relay should support vendor class option. But in the message processing in the "Section 22.16 Vendor Class Option" does not mention any thing about this for relay . It only mentions about how the client should process this. Can some one please clarify this what should be done for dhcp6 relay ? regards, keshava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/dhcwg/attachments/20040827/5cb1a8a8/attachmen t.htm ------------------------------ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg End of dhcwg Digest, Vol 4, Issue 38 ************************************ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 29 06:37:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28929; Sun, 29 Aug 2004 06:37:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1N0Q-0004pJ-UJ; Sun, 29 Aug 2004 06:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1MmZ-0003TP-JZ for dhcwg@megatron.ietf.org; Sun, 29 Aug 2004 06:19:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28468 for ; Sun, 29 Aug 2004 06:19:27 -0400 (EDT) Received: from smtp1.agni.com ([202.53.160.4] helo=mx.agni.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1Mo4-0007up-5J for dhcwg@ietf.org; Sun, 29 Aug 2004 06:21:06 -0400 Received: from inspbg.com ([202.53.160.107] helo=server.inspbg) by mx.agni.com with esmtp (Exim 4.12) id 1C1Mlh-0002vL-00 for dhcwg@ietf.org; Sun, 29 Aug 2004 16:18:37 +0600 Received: by SERVER with Internet Mail Service (5.5.2448.0) id ; Sun, 29 Aug 2004 14:57:04 +0600 Message-ID: From: "Dhaka . Razzak" To: "'dhcwg@ietf.org'" Date: Sun, 29 Aug 2004 14:57:03 +0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-MailScanner-Information: Scanned by agni's email virus scanner at smtp1 X-MailScanner: Clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6, BAYES_00 -4.90) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [dhcwg] Help about MS Exchange Server 5.5 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Dear All, OS: NT-4.0 with SP6 MS Exchange Server 5.5 Problem : Server inspbg.com is configured to dialup automatically every 45 minutes and if the domain storage place there is no mail then it will be disconnected after 10 minutes. But now a days it is not working properly. My ISP provider told everything is ok at their end But I need to knock everyday over phone to force the mail to my server. Can anybody help me to find out the problem. Best regards, Razzak Razzak@inspbg.com , administrator@inspbg.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 07:35:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08892; Tue, 31 Aug 2004 07:35:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C26n6-0004Jo-PQ; Tue, 31 Aug 2004 07:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C26iO-0002wJ-Fb for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 07:22:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07785 for ; Tue, 31 Aug 2004 07:22:15 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C26kL-0000Kx-JF for dhcwg@ietf.org; Tue, 31 Aug 2004 07:24:18 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2004 07:34:00 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7VBLgUu022392 for ; Tue, 31 Aug 2004 07:21:43 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-182.cisco.com [10.86.242.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALE99237; Tue, 31 Aug 2004 07:21:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20040831070538.02d62fa8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Aug 2004 07:21:38 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [dhcwg] Revisions to draft-ietf-dhc-agentopt-radius 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org In response to comments received during the IESG review of draft-ietf-dhc-agentopt-radius, we have published draft-ietf-dhc-agentopt-radius-08.txt. The most important change in this revision is the specification of the IP-Framed-Pool RADIUS attribute in replacement of the Class RADIUS attribute. This change was made because the Class attribute is used for other purposes in some RADIUS deployments and servers, and because the Framed-Pool can be used to carry the name of a policy that should be applied to the DHCP client authenticated by the RADIUS protocol exchange. Here is a summary of the other differences between the -07 and -08 revisions of the specification: A paragraph was added to the end of section 1, Introduction, to clarify the applicability of the RADIUS Attributes Sub-option: The scope of applicability of this specification is such that robust interoperability is only guaranteed for RADIUS service implementations that exist within the same scope as the DHCP service implementation, i.e. within a single, localized administrative domain. Global interoperability of this specification, across administrative domains, is not required. A paragraph was added to section 2, Terminology, and the section "RADIUS Server Behavior" was removed to clarify that the RADIUS Attributes Sub-option does not affect any specification of the behavior of RADIUS servers.: The use of the standard keywords MUST, SHOULD, MUST NOT and SHOULD NOT within this specification are with respect to RADIUS clients and servers that implement the optional features of this specification, do not create any normative requirements outside of that scope and do not modify the base RADIUS specifications, such as RFC2865 or RFC2866. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 08:21:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11981; Tue, 31 Aug 2004 08:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27X8-0003Jd-Mq; Tue, 31 Aug 2004 08:14:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27OR-0002JU-W5 for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 08:05:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10969 for ; Tue, 31 Aug 2004 08:05:42 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C27QN-0001WK-16 for dhcwg@ietf.org; Tue, 31 Aug 2004 08:07:46 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7VC2BOK019187; Tue, 31 Aug 2004 14:02:11 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7VC282q012340; Tue, 31 Aug 2004 14:02:08 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 31 Aug 2004 14:02:08 +0200 From: Stig Venaas To: Robert Elz Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040831120208.GM2203@sverresborg.uninett.no> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <6493.1093586912@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6493.1093586912@munnari.OZ.AU> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz , jdq@lucent.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 27, 2004 at 01:08:32PM +0700, Robert Elz wrote: > Date: Fri, 20 Aug 2004 08:44:14 -0400 > From: "Bernie Volz" > Message-ID: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> > > | I'm OK to restricting the Lifetime Option to replies to > | Information-Request's. > | > | The client MUST ignore a Lifetime Option that is in any message other than a > | REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > | Option number in an ORO except when sending an INFORMATION-REQUEST message. > | > | The server MUST NOT include the Lifetime Option in any message other than a > | REPLY to an INFORMATION-REQUEST. > > I've been reading all of the messages on this topic (catching up) and I > haven't managed to find a reason why anyone would want to add this kind > of restriction, I just don't see the need. > > You seem to all be imagining that things have to get much more complex > for the clients if they get two timer values, and they're different. > But that's nonsense. I pretty much agree with what you say. The reason the option isn't needed when you have leases, is of course that you can set the lease time short, just to ensure that client update other config. I agree that it could still be useful though. I don't know what people think, I have no strong feelings myself, but we could relax things a bit perhaps. But there is some added complexity and it isn't essential. It could also be extended later if necessary. We could tweak the spec to allow what you say, if there's agreement on that. But most of all, I want to come to some conclusion really soon. I posted a mail with subject "Attempt at text for draft-ietf-dhc-lifetime-02" where I tried to write text that most so far seems to agree with. Most of it is based on inputs from discussions on mailing list. Bernie gave some comments that I plan to include. I did not say any about what should happen if some config data is removed from one client update to the next. Do you really want that in? I'm not sure I do, since as also some others agreed to, it's a more generic problem. If I were to write text, I would say that it should indeed be removed. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 08:26:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12220; Tue, 31 Aug 2004 08:26:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27ee-0004Dw-CU; Tue, 31 Aug 2004 08:22:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27Xp-0003Na-W1 for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 08:15:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11742 for ; Tue, 31 Aug 2004 08:15:25 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C27Zn-0001is-EE for dhcwg@ietf.org; Tue, 31 Aug 2004 08:17:28 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7VCE3OK022210; Tue, 31 Aug 2004 14:14:03 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7VCE14Z012362; Tue, 31 Aug 2004 14:14:01 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 31 Aug 2004 14:14:01 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Message-ID: <20040831121401.GN2203@sverresborg.uninett.no> References: <20040825151559.GJ5677@sverresborg.uninett.no> <200408270854.10485.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408270854.10485.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 27, 2004 at 08:54:09AM -0400, Joe Quanaim wrote: > > Stig Venaas wrote: > > | A client MUST also use the default refresh time IRT_DEFAULT if it > > | receives the option with value less than 600. > > > > Do you agree with a minimum like this? It should make it harder to > > do bad things, and I don't see a use for <10 minutes. If <600, > > would you rather use 600 than IRT_DEFAULT? > > I think a minimum is a good idea, but it probably should not be reset to 24 > hours. That's probably not what an admin intended by setting the value that > low. I agree sort of. For the protocol, I like the idea of totally ignoring option with invalid value though, which means using the default. The server implementation should perhaps give the administrator a warning, or send 600 rather than the configured value. We could also do what you suggest though. Other opinions? > Also, are 0 or 0xffffffff a special case like elsewhere in dhcpv6? I am not > sure it's necessary; I am just bringing up the point. I think it infinity could potentially be useful, but 0xffffffff is in practice infinity anyway. If we leave it out now, we can still add it later if we want. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 12:50:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04191; Tue, 31 Aug 2004 12:50:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BaP-0001Ql-KJ; Tue, 31 Aug 2004 12:34:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2B51-0004Bp-Sh for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:01:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28021 for ; Tue, 31 Aug 2004 12:01:53 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2B70-0006jK-VG for dhcwg@ietf.org; Tue, 31 Aug 2004 12:04:00 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7516:52ec:cfc0:15e1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2911D1525D; Wed, 1 Sep 2004 01:01:52 +0900 (JST) Date: Wed, 01 Sep 2004 01:01:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) In-Reply-To: <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 24 Aug 2004 11:08:14 -0400, >>>>> Ted Lemon said: > However, let's consider your scenario a little more closely. You > acquire some information from the DHCP server. Subsequently, for some > reason, it becomes impossible for the server to respond to the client. > I have a couple of observations about this. First, the time at which > it becomes impossible for the server to respond is not the same as the > time at which the client attempts to refresh its configuration > information. The two events are unrelated. Okay, I concur on this. I also see that the scenario might differ based on whether the client moves to a new link or it stays in the same link. Instead of making further responses point by point, I'll try to summarize major points throughout the thread, and propose what I personally would envision based on the points (if you feel this approach is unfair, please say so). I'll also call the new option "refresh timer option" in the followings since that's the closest notion which we now seem to agree on. The case of moving clients is probably too difficult to provide a complete solution, but it would be helpful some considerations along with the this new option. Now assuming a still client (i.e., a client that doesn't move), we seem to be close to the consensus. - when the refresh timer expires, the client resends a new Information-request message. (it can do so earlier than the expiration time based on its local policy) - if the client gets a response, it (MUST) replace the old information with the new one. This also means if the response contains an empty set of some particular information, the client should stop using the old information. (BTW, there are two types of an "empty set". The first one is a response that contains the corresponding DHCPv6 option, e.g., DNS recursive name server option, with an empty list. The second one is a response that doesn't contain the DHCPv6 option. It seems to me it makes sense to regard both types as "an empty set"). - if the client cannot get a response, it (SHOULD?) continue using the old information because of the reason Ted provided. So, what I would expect in this document is as follows: - we basically concentrate on the case of a still client and explicitly say so in the document. - then we describe the detailed behavior for that type of clients as shown above (of course, based on a consensus in the wg). - we also provide some considerations on moving clients (in an appendix?), which would be something like this: + we assume we can detect the movement (or simply say it's beyond the scope of this work). I think we can simply refer to the beginning of Section 18.1.2 of RFC3315 if necessary. + when the client detects the movement, it should start contacting the DHCP server immediately, regardless of the remaining time of the refresh timer. In this case, how the client deals with the old information is up to the client based on its local policy (there can be so many valid scenarios as we've seen in the discussion). This should particularly apply when the client receives an "empty set" for some information or when the client cannot get any responses at all. However, if the client gets a non empty set of new information, it SHOULD(?) replace the old information with the new one. 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 Aug 31 12:56:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04649; Tue, 31 Aug 2004 12:56:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BaZ-0001f1-UP; Tue, 31 Aug 2004 12:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2B9N-0007fL-EI for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:06:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28464 for ; Tue, 31 Aug 2004 12:06:23 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2BBL-0006uZ-Mz for dhcwg@ietf.org; Tue, 31 Aug 2004 12:08:30 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7516:52ec:cfc0:15e1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 59CCC1525D; Wed, 1 Sep 2004 01:06:21 +0900 (JST) Date: Wed, 01 Sep 2004 01:06:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: commentson draft-ietf-dhc-lifetime-01.txt) In-Reply-To: <001601c48a40$8a411e80$6401a8c0@amer.cisco.com> References: <001601c48a40$8a411e80$6401a8c0@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org, "'Ted Lemon'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 24 Aug 2004 21:12:07 -0400, >>>>> "Bernie Volz" said: > You'd prefer IPv4 based information over IPv6? No, in that example, I assumed a dual-stack host. > And DHCPv4, if Inform was used, doesn't have *ANY* time to expire the > information - so I don't think you'd want to use this information in > preference to DHCPv6 information with a time? I think I would, since in this case I'd regard the "expired" DHCPv6 information as less reliable than DHCPv4 information without any expiration time. But I won't stick to this point any more as I (perhaps implicitly) said in my response to Ted. Let's just throw away this mostly-imaginary scenario. 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 Aug 31 13:06:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05441; Tue, 31 Aug 2004 13:06:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Bo8-0007NQ-Nx; Tue, 31 Aug 2004 12:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Ba0-0001Kh-A7 for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:33:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01556 for ; Tue, 31 Aug 2004 12:33:53 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bc0-0007vF-5m for dhcwg@ietf.org; Tue, 31 Aug 2004 12:36:01 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 352F01B2273 for ; Tue, 31 Aug 2004 11:32:17 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040831120208.GM2203@sverresborg.uninett.no> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <6493.1093586912@munnari.OZ.AU> <20040831120208.GM2203@sverresborg.uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8789608F-FB6B-11D8-8C0B-000D93C4B69A@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Tue, 31 Aug 2004 09:33:46 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 5:02 AM, Stig Venaas wrote: > I don't know what people think, I have no strong feelings myself, but > we could relax things a bit perhaps. But there is some added complexity > and it isn't essential. It could also be extended later if necessary. > > We could tweak the spec to allow what you say, if there's agreement on > that. But most of all, I want to come to some conclusion really soon. I think using the IRT option in a context where there is a lifetime already doesn't make sense, and should not be allowed. I don't mean the client should drop the packet if it gets both - just that the option has no meaning in the context of a stateful DHCP message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 13:07:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05603; Tue, 31 Aug 2004 13:07:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BzV-00024l-Fz; Tue, 31 Aug 2004 13:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Bd7-0003UM-Hp for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:37:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02154 for ; Tue, 31 Aug 2004 12:37:07 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bf5-00086W-EE for dhcwg@ietf.org; Tue, 31 Aug 2004 12:39:14 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id D48201B22C8 for ; Tue, 31 Aug 2004 11:35:28 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040831120208.GM2203@sverresborg.uninett.no> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <6493.1093586912@munnari.OZ.AU> <20040831120208.GM2203@sverresborg.uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhc-lifetime-01: dropping omitted options Date: Tue, 31 Aug 2004 09:36:58 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 5:02 AM, Stig Venaas wrote: > I did not say any about what should happen if some config data is > removed from one client update to the next. Do you really want that > in? I'm not sure I do, since as also some others agreed to, it's a > more generic problem. If I were to write text, I would say that it > should indeed be removed. I think we need to collect some experience on this, and that we should update the RFC later when we have more information. For now, we should not say what to do. I can easily think of a byzantine set of specifications for how to do this, but I'm not sure they're either necessary or correct. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 13:17:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06441; Tue, 31 Aug 2004 13:17:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2C0w-0002Wc-2N; Tue, 31 Aug 2004 13:01:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Blr-0006gn-QX for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:46:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03778 for ; Tue, 31 Aug 2004 12:46:09 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bns-00008A-Lm for dhcwg@ietf.org; Tue, 31 Aug 2004 12:48:17 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id B443A1B22C5 for ; Tue, 31 Aug 2004 11:44:38 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040831121401.GN2203@sverresborg.uninett.no> References: <20040825151559.GJ5677@sverresborg.uninett.no> <200408270854.10485.jdq@lucent.com> <20040831121401.GN2203@sverresborg.uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <419E9784-FB6D-11D8-8C0B-000D93C4B69A@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhc-lifetime-02: minimum value Date: Tue, 31 Aug 2004 09:46:07 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 5:14 AM, Stig Venaas wrote: > I agree sort of. For the protocol, I like the idea of totally ignoring > option with invalid value though, which means using the default. The > server implementation should perhaps give the administrator a warning, > or send 600 rather than the configured value. > > We could also do what you suggest though. Other opinions? There are cases where if any low value for this option is sent out over and over again by the server, it will cause operational problems. But this isn't something we can easily prevent without being too restrictive, and I think you have to be really well-placed on a network (i.e., on the DHCP server's network) to get much amplification out of a DoS attack based on this. In fact, when I think of how to come up with such a DoS attack, it seems like it would actually be very difficult. So I think the real risk here is that the server administrator will configure a too-low value, so I think the right way to address this is to say that servers SHOULD warn the server administrator through an appropriate mechanism if the administrator tries to configure a too-low value for this option. I think if you try to specify this on the protocol level, you're just making needless trouble for yourself, and not getting any benefit from it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 13:22:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07009; Tue, 31 Aug 2004 13:22:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2C1v-0002c7-AD; Tue, 31 Aug 2004 13:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Bnt-0007DC-SQ for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:48:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04056 for ; Tue, 31 Aug 2004 12:48:15 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bpt-0000EK-TW for dhcwg@ietf.org; Tue, 31 Aug 2004 12:50:23 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id B60A81B242B for ; Tue, 31 Aug 2004 11:46:43 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <8C0D764C-FB6D-11D8-8C0B-000D93C4B69A@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Tue, 31 Aug 2004 09:48:12 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 9:01 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > So, what I would expect in this document is as follows: What you've proposed sounds good to me! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 21:39:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22046; Tue, 31 Aug 2004 21:39:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Jyn-0007dv-NN; Tue, 31 Aug 2004 21:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2JuI-0006mC-ER for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 21:27:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21413 for ; Tue, 31 Aug 2004 21:27:25 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2JwN-00056n-4o for dhcwg@ietf.org; Tue, 31 Aug 2004 21:29:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2004 21:26:53 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i811QpUu020159; Tue, 31 Aug 2004 21:26:51 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-207.cisco.com [10.86.242.207]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALF64703; Tue, 31 Aug 2004 21:26:49 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" , "'Joe Quanaim'" Subject: RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Tue, 31 Aug 2004 21:26:50 -0400 Organization: Cisco Message-ID: <000001c48fc2$c1a09310$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040831121401.GN2203@sverresborg.uninett.no> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig: I agree with Ted (in response to your message) that the server SHOULD warn if the time is below the minimum. I don't agree with you that the client should just ignore the option if the value is below the minimum - it should use the minimum. I'd follow the convention used in RFC 3315 to declare 0xffffffff as infinity. 0 isn't special - though as it is below the minimum, the minimum would be used. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Stig Venaas > Sent: Tuesday, August 31, 2004 8:14 AM > To: Joe Quanaim > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 > > > On Fri, Aug 27, 2004 at 08:54:09AM -0400, Joe Quanaim wrote: > > > > Stig Venaas wrote: > > > | A client MUST also use the default refresh time > IRT_DEFAULT if it > > > | receives the option with value less than 600. > > > > > > Do you agree with a minimum like this? It should make it > harder to > > > do bad things, and I don't see a use for <10 minutes. If > <600, would > > > you rather use 600 than IRT_DEFAULT? > > > > I think a minimum is a good idea, but it probably should > not be reset > > to 24 > > hours. That's probably not what an admin intended by > setting the value that > > low. > > I agree sort of. For the protocol, I like the idea of totally > ignoring option with invalid value though, which means using > the default. The server implementation should perhaps give > the administrator a warning, or send 600 rather than the > configured value. > > We could also do what you suggest though. Other opinions? > > > Also, are 0 or 0xffffffff a special case like elsewhere in > dhcpv6? I > > am not > > sure it's necessary; I am just bringing up the point. > > I think it infinity could potentially be useful, but > 0xffffffff is in practice infinity anyway. > > If we leave it out now, we can still add it later if we want. > > 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 Tue Aug 31 22:00:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23257; Tue, 31 Aug 2004 22:00:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2KA8-0001lt-LL; Tue, 31 Aug 2004 21:43:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2K5h-0000dv-8I; Tue, 31 Aug 2004 21:39:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22035; Tue, 31 Aug 2004 21:39:11 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2K7m-0005HL-33; Tue, 31 Aug 2004 21:41:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 31 Aug 2004 18:32:18 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i811Vqb7004788; Tue, 31 Aug 2004 18:31:53 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-207.cisco.com [10.86.242.207]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALF64861; Tue, 31 Aug 2004 21:31:51 -0400 (EDT) From: "Bernie Volz" To: "'Keshava'" , , Subject: RE: [dhcwg] dhcp6 verndor class option Date: Tue, 31 Aug 2004 21:31:50 -0400 Organization: Cisco Message-ID: <000101c48fc3$748d79c0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <001f01c48c3f$86a44f80$1604120a@keshavaak> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: maoshx@huawei.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable If there's relay specific information that could be used by a server (or other relay), there is no reason the relay can't include this in its Relay-Forw message (and the server return information in the = Relay-Reply). Note that Appendix A, Appearance of Options in Message Types, indicates = that these are valid: Status Rap. User Vendor Vendor Inter. Recon. Recon. Code Comm. Class Class Spec. ID Msg. Accept R-forw. * * * * R-repl. * * * * - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Keshava Sent: Friday, August 27, 2004 10:10 AM To: dhcwg@ietf.org; ipv6@ietf.org Cc: keshavaak@huawei.com; maoshx@huawei.com Subject: [dhcwg] dhcp6 verndor class option Hi, Can you please clarify in he RFC 3315 (DHCP6)=20 "Appearance of Options in Message Types" section mentions that the = dhcp6 relay should support=20 vendor class option. =20 But in the message processing in the "Section 22.16 Vendor Class = Option" does not mention any=20 thing about this for relay . It only mentions about how the client should process this. Can some one please clarify this what should be done for dhcp6 = relay ? regards, keshava _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From jkpwang@szjkp.com Tue Aug 31 23:52:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29740 for ; Tue, 31 Aug 2004 23:52:36 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2MCu-0007L6-U4 for dhcipv6-archive@ietf.org; Tue, 31 Aug 2004 23:54:50 -0400 Received: from [219.133.10.217] (helo=dhcipv6-archive) by mx2.foretec.com with esmtp (Exim 4.24) id 1C2MAc-00075R-GZ for dhcipv6-archive@ietf.org; Tue, 31 Aug 2004 23:52:26 -0400 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: =?GB2312?B?w8C5+taqw/vGt8XGy/62pbfFtPPG91JFTUVD?= 11:53:22: To: dhcipv6-archive@ietf.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf" MIME-Version: 1.0 Reply-To: jkpwang@szjkp.com Date: Wed, 1 Sep 2004 11:53:26 +0800 X-Priority: 4 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Message-Id: X-Spam-Score: 10.0 (++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 8e4473fc24b2a73dd257b90bcbb5660b This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: multipart/alternative; boundary="=_NextPart_2altrfkindysadvnqw3nerasdf" --=_NextPart_2altrfkindysadvnqw3nerasdf Content-Type: text/html Content-Transfer-Encoding: quoted-printable =  =CB=FE=B6=A5=B7=C5=B4=F3=C6=F7=B5=C4=D7=CA=C1=CF=D2=D4=BC=B0= =B2=FA=C6=B7=CD=BC=C6=AC=B7=A2=CB=CD=B8=F8=C4=FA=A3=AC=C7=EB=B2=E9=BF=B4= =A3=A1=C8=E7=B9=FB=D3=D0=D2=C9=CE=CA=A3=AC=B5=E7=BB=B0=C1=AA=CF=B5=A1=A3=  
 =C3=C0=B9=FA REMEC =BC=AF=CD=C5=B9=AB=CB=BE N2002201 180= 0MHz TMA =CB=FE=B6=A5=B7=C5=B4=F3=C6=F7 =20 7200=D4=AA
 =C3=C0=B9=FA REMEC =BC=AF=CD=C5=B9=AB=CB=BE G20= 00701 900MHz  TMA =CB=FE=B6=A5=B7=C5=B4=F3=C6=F7 =20 7200=D4=AA
=CB=FE=B7=C5=B5=C4=D3=C5=CA=C6
=A1=F4 =C0=A9=B4=F3=BB=F9=D5=BE=D3= =D0=D0=A7=B8=B2=B8=C7=A3=BB
=A1=F4 =D4=F6=C7=BF=C8=F5=D0=C5=BA=C5=B5= =D8=C7=F8=B5=C4=B8=B2=B8=C7=D0=A7=B9=FB=A3=BB
=A1=F4 =B8=C4=C9=C6=CD= =A8=BB=B0=D6=CA=C1=BF=A3=BB
=A1=F4 =BD=B5=B5=CD=B5=F4=BB=B0=C2=CA=A3= =BB
=A1=F4=20 =BD=B5=B5=CD=CA=D5=BC=B0=B7=A2=C9=E4=B9=A6=C2=CA=A3=BB
=A1=F4 =CC=E1= =B8=DF=BB=F9=D5=BE=BD=D3=CA=D5=D0=C5=D4=EB=B1=C8=A3=BB
=A1=F4 =D4=F6= =BC=D3=BB=B0=CE=F1=C1=BF=A3=BB

=D0=CD=BA=C5= : N2002201=20 1800MHz TMA
=D6=F7=D2=AA=BC=BC=CA=F5=B2=CE=CA=FD:
Descript= ion 1800MHz TMA
Frequency Band=20 1710 - 1735
Op B/W (MHz) 25
RX Gain(db) 12
Rx NF(db) <1.4 =
Tx=20 Loss <0.5
 
=D0=CD=BA=C5: G2000701 900MHz TMA=20 =
=D6=F7=D2=AA=BC=BC=CA=F5=B2=CE=CA=FD:
Description 900MHz TMA
= Frequency Band 895.0 - 910.0
Op=20 B/W (MHz) 15
RX Gain(db) 12
Rx NF(db) <1.6
Tx Loss=20 <0.55
   
=D7=A3=B9=A4=D7=F7=ED=98=D0=C4!
 
 =20
***************************************************
=C9=EE=DB=DA=CA= =D0=BD=F0=BF=AD=C5=F4=B5=E7=D7=D3=D3=D0=CF=DE=B9=AB=CB=BE
=C1=AA=CF=B5= =C8=CB:=20 =CD=F5=D3=C2
=B5=E7=BB=B0: 0755-83658905
=CA=D6=BB=FA: 13715328825=
Q  Q: 102419409
MSN=A3=BAbon0524@hotmail.com
Email:jkp= wang@szjkp.com
=B5=D8=D6=B7:=20 =B9=E3=B6=AB=C9=EE=DB=DA=C9=EE=C4=CF=D6=D0=C2=B7=B1=A6=B0=B2=B4=F3=CF=C3= =BC=D7=B4=B117=B2=E3A
=D3=CA=D5=FE=B1=E0=C2=EB: 518031
http://www.szjkp.com
*************= *******************************
--=_NextPart_2altrfkindysadvnqw3nerasdf-- --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="REMCES.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="REMCES.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEAtAC0AAD/4QliRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAUAAAAcgEyAAIAAAAUAAAAhodp AAQAAAABAAAAnAAAAMgAAAC0AAAAAQAAALQAAAABQWRvYmUgUGhvdG9zaG9wIDcuMAAyMDA0OjA2 OjIyIDExOjAzOjA4AAAAAAOgAQADAAAAAf//AACgAgAEAAAAAQAABkCgAwAEAAAAAQAABLAAAAAA AAAABgEDAAMAAAABAAYAAAEaAAUAAAABAAABFgEbAAUAAAABAAABHgEoAAMAAAABAAIAAAIBAAQA AAABAAABJgICAAQAAAABAAAINAAAAAAAAABIAAAAAQAAAEgAAAAB/9j/4AAQSkZJRgABAgEASABI AAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwP FRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQO Dg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEI AGAAgAMBIgACEQEDEQH/3QAEAAj/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEF AQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMi cYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj 80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcG BTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kST VKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/ 2gAMAwEAAhEDEQA/ALJtEcKBtMJoSLdFepqWidaTzKiXzx81J7YKgGENLohp4+XKBIG5SLOwY+o6 InyUC53zTl1Z4cFAuaASSIHdN4h3H2po9isXuCi57wpy1wDmkFruD2PwTbBCSkRtcPIqPq6QU9rN JQCCEaUkLgVBxDhHdDJKYlGlLPJaDpOhEeKBuPgjPlBIQpNsSQeQmmBAMjzTlROqSn//0CB4lM+6 msD1bG17j7d5AmPig+rCBmH1bMcNJ0L5HMwGnY5oLfarmaYx45TO0RZauOPFIR7tm7Jo2EMurNjm ksEgyB+c3X37UXDc5+PQ9zg4ljpIiJD9fo+1Yd9eQwODLtorr3gWyJA3e1gbv/eW1guJBrFdldVb d1XrFhcWWEWteTTDPzlUGf3QJacJ1jXVs+0IWOvW2x9lx3+59YJ8f9yY4ON/o4+BP96OwafNShBT UPT8fwd96gen0eLh8x/crsJiEktA9Or7PcPkFA9Nb+//ANELRIUSElOW/pLHFrt4lvGkffDvd/aU T0hzvokH5FahCDky1jH6wyyt7j4AO5/6SNnuUUOwcnIwDjbTaAWkxGoMKjewV3WVAz6by2fgf/Ir f6rUW0tDuzu/hLx/1K5lt7nZDxZ7nWWWbn7vdub3LI+h7djVLimRIgmxssnG4ggUyIQzoUeAhuVh if/RZ+I9w0MLOuwr7LQHWOZsmHMjWf6y2y8a8ad1RyrHiDVsa6STvnUAfmwr064TxC49WpG7HCaL WPTH2u1tZW0ghzQyNw7/AOE3KeB0phvozC93taHM13BzmhrLD7vcxn+D2LD6qRd1Wp1j5f8AomNf VqAJO/ZMfpG7l1HS/S+xY/oklhN2ruZ3gu4lVJyjfDGNeLYiJVcpW6FfB+KnCasEtMDuplp8CmLm EJoUyCmhJLAhRIUyFEhJTAhPWWtfLhIgiAJ/BIqJSUj6u2cXdB4Bg88tXH24mTj5Tb7iHtcfVdYI BLHEsNjmfme7duXW5LQce0fyT+Gq53qltIqa9x1pxb2WN8nu/QB3/GPc7Ym5JmA4huCPr6vlTEA6 HrbA8woPQemV2twaRbIdGk8hs+xGcFoA2Ae7VIo12f/SMddZVXKr3uqY0gOeSASYAJjVzlc2k6Ac GVA002GLWye3Ku5I8USO9NSJogvOU0P/AEvqO2ive6du8EiTA9zNnqbf51dB0kNbgYu4ENYHh/c+ 6Du0+nx9JS+wYb2lprBntuPfx1UzWHADVrW8AAafeFCMB1JIZfeGmhbX2zG43R5bXf8AkU4zMc/4 T8Hf+RVL0PN09tB/5FQfQ6CA4jTkgf7EvYPdXvDsnxOr4uXv2nZ6ZAJJmSZ42jyRjkU/vtWY3Hcx sB+k6nb/AOZKD2WDv+Ef9+S+7yT7wdU31fvt+9RN1X77fvCx3usaY3fl/wDJIbr729z97v70vu8l e9F178zHx6X32PHp1iXEEExMfRHxUacujIpZfU8GuwSwkgEiY+isG99t7fTeQayfe0kmf86VNtzm AMaxoY0Q1oMAAcDhD7vNPvRd8OYdNwIOhEjhc39Y6PQxqSyCBe9m7TUFgexrv3vT2vRftzm81Az4 n/zBU8n7VfYLHZBBDXNYwNhrGv8AptY2fz/z7PpoS5efa/sSMse6Wd7Q794A/ghuCesbamsmS0Bp PHA0SJVobC2Dq//TtAgHXvyoP04Vl9IcJB80F9Ok/er1tRCXmD4jgqLMl4J11Kd1bmj48qrYCD5p wQW6MqyefinGU/XX7wqG8n4hSFhj8iSG3ZkOJ1cTPihOucWjXtp8EJ1s/HsolxjTsUksLbHcoXqO Ig66aKb9ePuQu34JWpjvjs0/ESm3HuAfNO4KMhG1UjeT/rCEUZwn5ILgULSsPBMQmJI1ScfBBL// 1NAvE66qJaC0w6PI+CGa9B3HkpMY8aawPuhXmqis3eWirXggcfJWH6H3IL9UkNQn707U72QfJM0f JFCzjH9yiRGs6HgqTgOUOY0/NdyPP95JLEuPfnsn0LZ7H8qbRw10cOfNM0wRPBMfNJVLxKG4IjdD 5KL0lIiPn4qDx/sRNVBxRUhPKieI8ERyGe6CX//Z/+0LnFBob3Rvc2hvcCAzLjAAOEJJTQPtAAAA AAAQALQAAAABAAIAtAAAAAEAAjhCSU0EDQAAAAAABAAAAHg4QklNBBkAAAAAAAQAAAAeOEJJTQPz AAAAAAAJAAAAAAAAAAABADhCSU0ECgAAAAAAAQAAOEJJTScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D 9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAABgAA AAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////////// /wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////////// A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAAAkAA AAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAAAawAAAAYAAAAAAAAAAAAABAgAAAIwAAAABQBS AEUATQBDAEUAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAjAAAAQIAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADhCSU0EEQAAAAAAAQEAOEJJTQQUAAAAAAAEAAAAAThC SU0EDAAAAAAJAgAAAAEAAAA9AAAAcAAAALgAAFCAAAAI5gAYAAH/2P/gABBKRklGAAECAQBIAEgA AP/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwM EREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAHAAPQMBIgACEQEDEQH/ 3QAEAAT/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEA AgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFi MzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF 1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFx IhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPT dePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AMMt 7QpsbHn4FSAkA9j3VzC6bm5u4YlBu2AeoZaxrZ+jvtudXU3+rvW2DGMeKREQNyXM4STQ18kTRI1U gxx+jqfJAzsXrNN9eMMfIZqXXHG9G2Wlp9L072vuo9tzf01f84qfTOl9fv6tVjdWdYzGDPVv9Yl1 JYW/o2vGM79M57yz9X/nP9KocnPY4CRHroWOEx9Xkz4+VnKrPB52zZ1/pLck45yIM7TaAfTnw9Qf 9V/NrRfk4VX08mls6ibGa/D3K3d9Xg/Gc12Zh5PJrxP2cyqkGP5sZLX/AGuln/DMb6rFYw/8WvQM ms5VozgNpc7bZUyuQPo4rHU2XWMr/wAE++z3/wCEVPF8UymxkxxHWJhLjj/dl8vqbEuSgKImT9NX JrycW9pdRa26DB2GQO+rlPcIiBH4oZ6ZldO6jn1ZtrbrLbhdVc1grbbU4O2XCusMrqfpstpaz2Wq x6ZmO/8Ar7VpRyk4PdP7spf4rSlADLwDuB9r/9Cs+nVafQMOnMyWY90uol7nAGNQ2dFRta6TPdbv 1UqIyK3kQC2wg+MDZotHnj+o85RDV5YfrL7RLuM6F0qk7TQ4gGC5xIb8fc+v2q6zpnTK2B4rqFek O2gj3fR9zt30pQXdOwH2Otfjsc95LnEyQSdXO2k7fcrUnaGabBENgQI+j7f5KyiA2xfU2xFbGEhr Gtgxo0D+Cjef0Np/4N//AFJRYWd17qmH0jpeRnZpc2hg2EsbudLwWMhstRCnk/rGHXZ2MC0jbQ5o HYgP27/7W1Q+yH1/OZny+Khk5VGdfVlYz/UofVuY6CDDnueNzPpNft/NWhtf9q2R+bz5bd29bI05 aMP6k3KMj94/wh/3L//RVwlxj5LoPqpjNre60TusDnPniRtqG3+y1YvpuL9JP+1dN9XqyxmvZh/F yvc+f1UR/XH/AEZNXlT6z/dP5xdoBSATNCmAs1uLQg5VddmPayxjbGlrva8Bw4P5rtzVYAQ7h+if /VP5ElPn+dh01dUsNDBW17WyxohoO6xvsYPo/Rb7WrQ22faP7OyO8bdqnkVNfnPc6QA1gP8AnWo8 n7VG07Z40njla5n+qA7QLjSP6/8Awg//0tvHxmzJEnz81t9KYB6kCIAH4rOpEdueJWt0waWHxI/i pubkTwjx/Y0uS+aZ8K/FvAKQCYBSAVQt9QCHcIqf8EZDyR+hefJIbqecdQHZDp8Wo32cevHnyjCs G8uI0lv5Aj7T6/HfidVf4zwj+65Pt/rCf64f/9PqmtAGvZX+iOufhiy9gqufBsrbqGujVrZL/wDq lSDdzo7AlaXS/wCjE+LyfwCfzJ1gP7zU5Ifzh/u/903RqpBMIUgq7dXHIWd1/H6ldgkdNvGNcJl7 jEg8N+hZ+ctEchDzP6O/5flCQ3CDsXKxBkGx/rAb2vAaQORAg6K56bftcdt3Mdvih1N/Sz/KH5Go k/rUTrP8Fcvrpt9GlwgaG/m+r//U7Ntbp0Ent8Sr2IwU0MrDh4kz3KoMbBkaGZBH+xPkftV99TsU 44pLT6xtrBduDmnc0+32en6nqO/f9L9GpMsDIg9mpy2QRsEVf7HVa8kw10k9pVXB6xgdQdkNw8gW nEf6WRyNr5cNvv2/uOXH29dzs66nA3MeLG1ZFeS532dkVNdlPZkOxmfpKM2v9H7X1s/7dRfqubnd Sza6Rj032u+1+qA64D1D6dWOLvUre6v+es9J6hhESHmLDbyEwu+m72n2hg/wjf8AOCV11d1OxjwX kjQGeCHOOn8leZH/ABnZlePmMbdlWGq8MpzPs+OWhh3j3sb6Da3v27qmfpf662cD6z9fy3Mb9qxj ArdstY5jrBaLNjW+j6+62trPVydjPT/S11pcEgfUDHxKTtoQfAPW0gF8/wAofkalP65u7TMqOFY/ JxasmxoqdYN1jATAIOyA4trc5vs/OYh7X+v6sHbzzrHCsAjhOv6LTndx0/TBf//V7qusTqEesQ4A 6Dy5UG6HjX+9J5AkqbdpgAB47CGO5zrcvHc29zK5nFIrkbP5v0q/53+c9b2qx0fMp/amW2pgrDHB tJDSwva6zIyd21zW7fS9RtexdFfe/bAcZ+JVDDwKrc8XWCdoIA81Fy/JY8eWecznZgIcFj2/RHhH DH/BVn5yWQeyIgcRvi7XK3K6j9Xek3dSfYemUNosx3udeKtrfVJH6QOZ7ftHu/Rs/wDA0HH+ruPX eci67IexutYZsDt8jYbi8e6r9/auyfQ3aANI47Jm7o0J0T5RMjYmQP3d1wlIUKAobj9Jhg7W4FIJ k7fHxJKlt9+6P96mxuonQeB8USGRE/PslWnD4Uo6i+z/AP/ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgADYALgAwAAAAAQA4QklNBAYAAAAAAAcAAwAAAAEBAP/uAA5BZG9iZQBkAAAAAAH/ 2wCEAAoHBwcIBwoICAoPCggKDxINCgoNEhQQEBIQEBQRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwBCwwMFRMVIhgYIhQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIBAgCMAMBEQACEQEDEQH/3QAEAEb/xAGiAAAABwEBAQEB AAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIE AgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNz wjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWltcXV5fVmdoaWprbG 1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6 EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0Q4IW klMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWFlaW1xdXl 9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6 ipqqusra6vr/2gAMAwEAAhEDEQA/AIwpqd+mbwl1QX/ZFB3yKTyWdd28clTVVHdesYYjei98I2Z0 qEjieGxAyQJtSQhlAeOp+0DvkSd2IFxXFWUbdMJNhIBDmAJBXt2w8mue/JsmvxU69T8sG7MSDlYL XianJhja4mMceQO/2iDQ9O2K7KynmignlIPhVSd+PvgLbHkseFuNamlevavhk2ohYFoOlGfvkL3T VLkjCJxPY0yQUCl3w8ifEbYFPNsLQ1J5HwydBiBSrB6Syq8y80B+KOtKjute2RZgKziJixjUopYl EJ5UUmqryP8ALiAnmFipUVPbtkmIDbtJKR6rlvAUxU7uKkJQinLoMU05ErtWg8cJKQFxPRQa0OBV x3HgPDFDRAA374pIWg0U/PJWhwIDDuTgW17MTVlH0YGVrTTjuKMemFiXJQCh6jEqF/IBK03rTBSe QWCqgchSvTFjbYYA9NvHJMrXsasOJ6DemBXeonX9roB4e+CltpSaN7muLKOzVBTkMWFdVtatyr2w 0i+rQ5AVI77YhmGyKkBd+5wsZ7ruB5LHGS7ttwHv4YLZIpYrmCT0ylJIG4sDvQnbjtgsEKvZrq1d 4ZAFKmpjIDAH8Vx2kLYc1l5ezXkiySEswUKCadAP8kDDCAiNkUTzUKt6fIGmEc2ce5tjsvxdeuNJ LlUVpWowKA4NUMBtU04D2wsIjm77FakhuxBxSBTdQKdtu+LJbQEBj3w2w4VWPh3Fci2S3DjGnffc fPDbWQulZ2f1JG5lxuPfAA2dFEI1dht3woDqUJZTSnbFjyNtmlaE/I+GKbWy7KD2wR5qStjZSeTb j/PvkisTvbizNUAcUwBiebTKdvEfxwhEmgaN8O+2J3SGwSFUympr8AONboJcS1RQAGtem+NKCu4h vs7udgB132xpJLuQCGNkHqD+Yb07Yhjd820kaig0KqSV8N8SGcdnb0Jrxr27YqCSs9MsQQaDvXEr T//QjKoSK983NurAXUPIYVLbGrVpsNtvHLA1SO67YChNPcYJNg5LSKCvjhDA81qcV+E9CcBFsgRE NsQW23A2IwgIMrW9G+EfRkpcmA5r+I4U74AbZ8KzYdOhw2w6ub4iKioHTEFEua4BQBTYjvhbI8lR GkK8CapUtx7VPfCGFOPJgAB9noMjTIm2xypyIPgRklbIU02xpBbqAaU2ySr+S9/tYAm16k03woDj uRig81RGAqK0B64sg0F79RSlDiyp25FF2GNIbR2+yuxHU03wlYnenNXrgUhxIJoeo64rbVADQbg7 4rS2lD0698NopVSrVAPE+OBIKwirMDuexw2hsL2H34FDZNFoNyMmk8lrFyAZD8I6DIhgWh0ySbXK OKqf92n7be37IwlAlTZKr2qx7nAyuha0MDvSnhTBSxlYb5dSCBhSeSmzADoMWvovowH+TUAH6Mhb Z0crMKnoB1I64SVXqRUGm474Ec1yyychvsp5H/m7+bCAvD5rhMzepJWhc/EBsMlSYRWKKAU3pjan ZvcsB1r0XFiDu5V25dAelcAK2u4hT128cS2LV+HdepPXFjEUvaNDGWNWIoajtU/Zb3xtXUBNVPKn TG2S6kbLRl+PrtgV3GgLUNDs1PDCrdEZSwqD+ycjbWS5iTHwUfHXZvbEth5LOKAcnrsdwMkEVQWy EEVA4jwwhjzbRFpyf4ieijAUAbrStRv9j9oeGRCZcl3GMKFUfEOg/jkkxCxmowpXj74AifNvjvQ9 Rv8AfhtADRWilqUPfDbKm+DSIGYjiNgMF0jhtZXjQhencb4bRVG10TJyLFaqOvgTXocKaC5vTHGN FAK13HU1ptX/ACaZEFiQA4Rg8FrQkkNXsO3TDab6LvTZnPGhAFOXQYCWQDSigINXIO4HQjADaX// 0Y4zEInEbn7QHb/mrN4A6q3AGlRuR1xIVwNTUGg61ySKXcRSjEe1MUtMKr1r/NhDGW60KpNK7jFO zYWtW6E7lcBssCAuIo29AKbZJkdljPU1pTEBAksp18P1YQwPNdUGgXcU64qS6pK8aVwdU9FSN+Bp QMadDhKg02pUDckk4V5IiG7EUUkQjRvVFOb1Zl35VTpxbBTMSUmb+wZJjI7u5MVFRQ+GFV3Hfkci EzDuRPt4ZJgvA2Brv4YpbWtSPuxSF/ORRtQAjbuTimy4MhpTr3HbGl4rXgA7D7R2r/XE8mQbdArF eauFJo61ow/2WAMVhK0LEbnCno0letDv+rCxiT3KrNA0SKiOJgW9RjTjT9jj+1go2yO6nU1FOnfE c0LG5Bu4B8MkWMua8FhQkgLv1wBTa1QxHMmg6U71yRSF0itUA0LHpTp9OQCyG7XEFgFqzU+JelD/ AJP82HdRzLkBAqTv4HJlENhutZgx22Ybb5EKHByBx49cSkFz+mK0fk3aooMQp5LFUsoJ69PamFER sq1qApPyPj9GRLJdGaF6b+K9BgSFqsvXeo7YaRDkvXc/PqMLNsLxY17nYYo5FcAQgpv8W5xCJdG1 BLmnX9WKabWMEMCakbKMWIitELEHkwHYA42gu9NhRTtTucSkWvZgnwr0br741sstnR0Vix6AEAe+ DojdoUIq1VbvTbFd2goIJ6r4YWUl6kMgHQeGLEbuGwA5Vp3xKd3OY1UA9964ApPJSY8TU/EOwOEG 0S2LaFi3qLUnp4ZIoHe3RixBIKt9o5FkAXOChAU+4bvTFmtINQBuOtMdkFskc+XU9MUbOZXoSTWO vxHFZ8nUAHWik/CPbIq6vZCKDqMaSujjehUDruVHhX7WNqveKQ1eQJCD8RBoPh/4rXEeSGldNmQF n/YZtht/Lx/42yVMLWmQs1X3P8o2A+YwEMgW5bh2hA599kApQjuxGCqKC//SjzRAmrmlM3pk6um0 Za0PSn442qm9TUKMkw4rXrQjfqOowEM1jhSdtvE4gbNZ2Lgqgip+bYqRva7jQ/u/iHj44R3IruWp zLEA8B1IP6sk1kElawFdt/5jgtk4BeBoCSd64UkbNCpFBtQ/hhYEKqooXkemRLMLiVJag3yVILht Q0qR7VwMyOTYb4i5H0e+Fiup8Qfv+GKkdXH8cKOK16h/hJ+z44U7rmCbEdT1Hvikja29hitONdqf filfzQbHc9sNKS1tTYUJ6YSo2C/9nbrkWZ2DVQR13xawbDRIANcLK9nKSKGu1OmGmoEtDkNx44Ob YGyaLRtsQE25QKhh9xwlAG9qjHlvTv0yLNY4O1PGtMk1kbqscJcu6An015SewG2RJpkohaOWY08C MkxG27TVLAjpXCiQsrygCq9QQwqRWhB8MiDbMhSK716jwxtjTmXkR4DCFIXIU4HfftjSQdmgRUHw wEoVF3qVB39sDMNxheLEjDajYL/SQKGDhmPVRX4fY1xtQ41AUgVNcKJKnIkNUUWtVOBEbWBqEhsL JfSi8+w8O+BktADmp7/hi1UudKbnc0oMkklrjuK9BuT88CndunN6KPh7nAyC88VQgGp8PpxpLfpm jyr9g7D5/wAuN9GHNTRWILkdO2FYjo2tOJam1cBSFOQgPxr16E9MkBbDkveOMT8SRIB/LUV/4IZE JJtpn4EqpAJ2LAdvDJMhyWcCp+E8uX0YFOzTIzGigLxHxEdPvwhFrlbktF2P81dsgeaeYU1Umh3I FTUCv3/y5K0VyVRFsHrQtuo7e+C2RFuMLyfCgBP2nkJoPvx5MZBxaGKnIGYg7quyj/ZftY7pJVZL pjCiwhYYwPi4LRj/AK7/AGmyIhush1QrAMOQXk3diSSMsGzAm1p9TiDWlKkYkpEDS74gF7Fvte2A pAW9PsivzxItBNP/04+GLivUFth7DN0XWDdrk9GWgpXJ9Wsk0WwgClieNex7/LDe6RDa3UIHSle2 AkslvADbt44QxMXR8PTY7li1FJ2Ap1+HCj+FokxkeJOEBiJEOkQOfgPEH7VNq5JBDvTAoAanIBab pUcfDJIMujlALAAe2EJC6gAoMSlxUAkjqeuEopeoB+XjXAGTQ4EuoB6ih7fPFiOrdSpAoScNJbYH mOm/WnTEMa3b335HcdMKS6jEinjikxJXMByPE18D74oKrHxIAJ+KoG/TfFkGmQxOee7KafRkhyWm 1ANSBRa7DIpXVA9z4YrbbDt08cUR5NEKpO/JfHFls4cS1OopX5DJXsxoNMey9MAVyggGu7HocKIu 4kAU79cASuFRWh2pU4lkFisTuTQdjhLCBs7ruLBaigPgfDFLXFSSK1HjitLakbA0B6UyRVsICOXX 6MiruQANRU9sirSKeVa4qFyL6nIAfEo2HthJWItaFjBFR06jAheDxPwMadsU2vSRuDcV3Lbn5Ypt yFqkuCR7HfEm1XN9n4QaV2B6/Tjank55HfiHGw2Hbb6MkAwtUanEe/T6MA5tjgXCUI3bocWNleoJ FBtTriyCzhUgivIblRUgD+bDbEDdo1Klj16nFJGzSAvHg6rHkvjQrIAT7g9R9OElFlzcqhfsgfiM DOnGMqa7kDwxtDnLKlBQgmtB2xVRr8ZC9epr2yTA8242BUlVqQdx44lY7t19uvbAzW8Q4IWpr1pi tWmFjoWoahDI1mnqiKnKOvxGvgP2sonmjA+pEcZPJBgQQh43VvUrxKEgU7HtlvNB2U2mkkHANRUH CigD/gyPtZIRAY2VymNYyH+J27DooGRPNmDsoFuZFfsg0A7ZY1k2vCk1+ImnT+mAsojZapY7k9Ou ErGRtcjig9Pcj7Q75ApErWlgzMzinxfCv8cKIy33Wl2ZiT/TCgk2u41PKux2BwR5MzC3/9SPDahT ev4fPN9J1AFOD0jrStTgiaTI7NBiftfZ8MksSaVHkNORO3QYsrU+TEbb06Y0gkkNcaGg22rT3whq coJ+2KNhT71zFFqPvwoLk+KjV3OKIm1zChoNweoyLIinBa0A6g1IySHHdttqHqMUuAozcRXxwoO3 J3I13XiMFBAkTzVF4N8anoNh44bZV1aZiPtbt44r0aA25NhDEcm6Fn4t0AqPowJ602akqAdjhU81 QKAeK7k4qdldbQvAZWkEa+B2Lf6uRJosq2Q8YJoO3euWE2iI2VqVXem2wGLYC0oqwXuT3wFr4iNl R1johViWIHOooQT+yP8AJxtPFam6Co3qR2wMSN22oACR17ZJnI04A0qDQYKQFylF3Bqw6HAil2zA BqBqk8ulfmMkzO6xeZU0XjtttWuKACHUUIKivt74p6NEfs128MUOcbUGK83Co4169MBQ4gpU8iRW tMkU8lqCrqg2JPU9N8BLCIpcyBBzDCp98FswtSUoTw3J2wFQVjGIJK7SKvEciGO53pRchKYDERso dtQtFG8gyHitggCvTU7M/C0g5Htg8VQNqKut1A1BGwIyQyMduiIKsAKtUEdsmJWyoruFFNKb5O1X UfjstR44oluFyqQKufh6im9BigbLXYFgCDTpsaYRyQS3HK8YIUlSwKsQeq1+w3+TiRaRsHEFkp9B /wBXACy6LY45KbVC/tHElgIlVQBSCrGlaV74lIG61zQ8q1NdsQkhbU8Pifirbt4VGAc2AFBaCSGI oAeh75JlFS4ihB3Y7ZJHkvjoYxU8ZAaU7U8cBRFePSX46FqdWO2V0yJpozMVooIr9ort9+TKbV7T VdSsuYtbloEbZ+BpWn/EsrlijPmFsoRmaR+bsS+5qe5JrXLAK2YmIWVVCSh+PvkiiLvtqxckE9CM iy6OXcBR0Gzf24UDlTq8XFQSq9CMKWnADV/D54GMl+1u/QEkbqe1fHHmx5LSlFVgQWPRe+AJpxK0 IYVJ6jDTLiDlDEAfs9sSiJoP/9WPVoaAFa7nN86olcN1C02GRITE7U2eJPy2yYVZ1FKVrgvdHRoE qen3ZNptvmOHA9TuG74GTTE/CaEgbcsIRIuIJJFKgYAbS2FRADWnthK8lzN8FQDzPTAGUzsuA+Co NXOxUdTkkU1XiabYoOwXjuRtX8ckkFpV5E1YUwUq0haqRtTwxIpC4kel9k1r9o4hSdm+o49fliSo aWta17d8lWyLXgBdz1YfDgUDe13JdgRuPDFSudjIau3OmwB7DwwhLXt9+PvSvB3oDTbp3xtk1VfU 22oPxwMb9VKs0zTO0j7u5qx/swVQZLag0U9uhwoIbioxAf7AO5G5pkujCRtp2HRfsV2Pf6RgDK9l q0rQdPDvhpRzpUZRSob7+uELPZcDs3YnIWyWFXCrToa1J8Rhtd3BCo61Jx5rVBaorVR+1+vCxiVR VRUdZFrI2ynkBwIO/IUPMZAkqpj4QCTyWpAPYgd8ndq2WUMWpWlCBkU2h5ZUBJaiUBO/SmCZ4Qgb lj+p+ZoYmMVn8fi3avscwcmcByYYCd0gn1i9mapanyzDOoPQOSMMQhjd3B/bOR/MSZiAC5bycdW5 fPCNRIIOMIiLVZUI3K07qe+XR1APNrOAJzZeY5VARzzWtWPfMqMhzBap4yGTWOpw3MYCGjeBy6GS zu08JTCN2X4g1VPRTl5osVeO4aKQOpo+49txxORMbFMCe9QoAeA6AU+WSQuVFfn8XEgbV707fNsb pJLm5KvFhRu2IXiU/SYitaV38cWdLyvxCrbKKn54sRzao7E0HXGwyc3wqgbYnv2wCkFYVRSVUVfw XHi3QBTaxSA8pQIx1HI0J+WJkgA2uaUFv3Q+PEeay2K081iZ5AKH9knf/gcWRFhYHSmwp8+mJKqc 5Zv3jEVHQDDEqQpKxdqkk16g5Jq4SSvYKDQE7dumJZ0A0h5/CWADHqe2JYwNtsxDlFA49Kjvikne mwm4Xl17YsqXMyqnv05d8ICJcloWi7ipP34F4WhRSSRUttv2w0xum61+HtgQ2jVG/bFlEW//1iDj V9+mbx1blJAdQKk7DGkDYFttq07dzkwtrKeAr3riBuxk0WdmUVp45JgbdRdyd6fZ98VXljQU+EUr T3wq0KkkjvjStcRXfr45EpbowkB6ilRhpHV1WO6mje1MUqgp1oAAPiGFJca1oOg6YUFoUIr0xKHc a/IYE0vUKVoMIS0Pb6ffChsU5KVWgH2q98QdkU21WNew6YpbjAFT3xZBsbk9sUKqoqrzYVHjgZU0 AOoNBXCUAincdyyj4cUe5tkC132AqcQktdE2361wJ6OFQMlbFUSNX+2aLuTkbZqaghqg/RkyWuP1 LhRj0pTucVkuKuaBenjkS2LWcqAoFTXrkgwkuUgkKx+HxxTbXAc6Dp2xJVxG/GgpkVWN4j7AGEIL RZOIanTcn28cEtlB7mG+Ytca4ka0tzxgQ/Ew/aP/ADTms1GoPJz8MNrY/mucl2KuxV2KuxVtWKmq mhGSjIjkqY2epSIwFaSVFHzPxZRLYuNlx3uzXRtUFzGUenqjp75mQl0LhkXsnQrUNIhVvf8AploN sTALlMfq1YV7jJFRELbgVIcLQ9R9GAFiYKTFnC1YGvavxU/ycBIDIjZUEYUniSEqPtdaYOOmQiaa k9LnxQ1PXAMo72XhlbLIYh6sk0UAG3xSDkaf5A5ZA5o0kYpHogn1jS4zSW4ErdhX+mQlqBTYMBKH n82afHGI1YinaNaf8MfibKvzA7myOlJQEnmy03AilkYmtSQNsfzR8mQ0ckPJ5vdTxitePgxapyB1 BPVmNILUH8z6i+6pGPdgW/plXjf1m8aQLrTzFfPOnq8ShO60piMxTLSQrZlAmheFZYySrivEjaub TFLiFunybFygLCzLxAHxHrXfLmu9tlNi3fCxILqHidvtYGQGytWNaFjuW6fRhISSAbUy3JiFHfri EcQXfBw3+I91xSeS3nQg9z0xQDSoYyFaViN/CtfpxZEbLIiOQHc4lEXMpQ0oRXvkVOz/AP/XI6np 28M3vV1izi1TtT3ySFjNUkHdule1PlgtpKrFEzlUWrM5Cqo8TkrSI0FqxsWq2zDYjG0gWXGoLINu O1ckgtIi1NWO29KYQhcVG1PuwWkgOZOIr2wJkNmlPwgnrTJBguYo3xFACBQcdshJkHUY07eOSqgp 3bl6gqcVlzaMTPvSi4qY9WxVem9OmKXI5ZSCNvuxCA2oLbHoOmG1G5cql60OwwqF/wAPGgY8u4pj agNA8epoPHFKo32QQQ1SQR+0KfzDAVteXBFBuuNMrU1epp2rQYWIKsAVI4nfuCMWTdUZgXB4jqBt X6cBWlicWBUjqOuBIDRU8wV2UbAYWNbrviJA6eJxSWo1ZpAi7kmgA64ZcmuB3XOEIofhUEgKN+nv gBbJCwujo4CnYYUA270wHpWo8cIKaVYY1J5NsOmC1pScA1Wv2T1HzxQ2qxGJnqeYNAtD0/m5fZwE pG6g8g4g1HEdTg4giQ2SnWdUt4tPm9KRTI3wqAdxXrmPPJbdDH0YGTU1zUTNl2AdkEuxV2KuxV2K uxVw2wg0VRlrqd3aOJIXoR4iuZhymravDFsq0fzTd3kogkhUuBX1ASP+F6ZYc3CLR4QKIuvNbQFk S1DMK8izkCv+qAMHjkszpu5L2833kklFSOPmQpPEtxFaeOCWU0y/KwA81O583azT04pkRBVT6cao TQ9WJXn/AMFkBMlkMMUvbV9ZmJZrlyD13xM2XgBR+tXTbtM7P3q3bBxlnECPJalHerEkHqcgbPNs qNWV/wAFdq/hgJLIV3LUVS1R27YLWTTqOZPT2whDQ40/mPjiQxtYXIYL44EiaIgJEqNTatKYjmyJ 2ZtYFls4yaU47D6c3OA+l5/MvJYrv3zIceIsLkVmJPYYSWwKyJzbivbc122H2uuC14lKQRlm2NAK rgsqaXGMrTl23AHuMIYyDYoWNe29clTN1S5DEVpkUczbarzcqO+9MUyLUpUAUFGpv0NMIYmTYKFa sWJpvv0yITzD/9AiDAtXoM3jrHF3G2x98bW2iNvnhDXPZfxoAwNCO+SJpmBs0tBt0oNsbQNi3QEK eXIDqtMMeSkKYIZyASCeg7UyYaYtnwIwJLiRx4kkV6eGBmeTYQFOdSKDfJopfCAGDkE9hTx8cgUw dIGDbtVlPwkZMoWlRtv88iim6kitdh2xWRbAqOv34lIbYlyOz/Zp2p44pXt6cSCh+LoxO4/2NMV5 KQIBOSYruVOO1K9aYClsGrEDp2wseLdcqhQSKCm5964CkNoVbYbDCyC6NFWu5Jr9GKiNK4HMbmrD 9n2+eBK1gQGUfEp8eoxXdYq0BIFMUhpFBYn7q4seq8/Cak/R442krOYDdNiKge+AnZAFNsjgimyn 7JPfJJ6qiK7KQXVVUHrvU+2AlAaqoG33ZEkM4hzPUUUH2A8cfECaaVCCWIp4g9MrOcWoxlDXFxbR CstxGtNqM4H8cjLMCNmQxFItX1oSp6Vs37gA0fYVyF2kRs0xc85IgiAu5Y/CoJP4ZiZsoAO7nRge iY2Xk7zLfBWh0+UI3R5B6a/8lOOabJr8MOcouQMEz0TeH8sPMbisj20Xs0tT9yK2Ycu2cA5ccv8A NbRpZdSiU/KnVWHxX9sh8DzP6kyr+W8f82aTpJd7m/KfWN+F9aN9Mg/5l4f5cxfzciPypQ93+Wfm NQhghheigMEmBLH+akix8f8AVyyPbOA8+OP+ap0p/opPe+TvM9kpa402YIBUsi+oKfOPlmXj1+Cf KcWo4ZdyTMrKxVgVYbEHYg5mg20kU1irvbJg9FZB5UFb3c9tssyfSygFbV46XMpr3yEHIEqCUMDQ 5cQFLYAoPHIhg2pFNjkqZjk04HXocEUFrmSKAfTiWE+TdRX3yJZglUhSSSVY4FLyueKhdzX5H/hc ACJSZyv5aSW8cJ1m+SG+uFDR6fbq08wBr/eiJft/8J/l5KNy5fS4+TPwsY8weXJdJY+m5ZQPiDqY 3H+tG+4y8YtmuOos0k6gEKTufHMdzQNkVGa0FN67YgbrI7FmGn0a1RamnHtm4xfS8/PcollQAEHp +OZAYGhyXKYwwWQmniMJTe7jVpAFJp44hB5uatF3qDUEd9sUyVAePwOoFRVWOxPywUyNNvE3EMlA D95xEkS8mo0UAU2cVq30YliFxqWD9+5Hf3xZ81g4Ly5LuR8NKD78Sig0earVty222/ywhiLf/9Eh WnDr17Zu3VjcOPh44q4qaUG57ZKO7GQpujcfl1yVLey5lFeXSvbvhRLc20XB26AYQEmVtADrUAeO Sthw7W1wJqyVevb/AG8CKXRp6m1Nu9fbGmXNcagALsB1xVy7kno1OuKHKlNiCS32T74bWMaabmDQ qBTv44EnYrgvNKnbwpiyEQXHoF22298LEuAI6CuIQuCVYDqR2OA80lpF4rtSpG9euSWO4bjVTsfv yJTWyzpJx7dyMkwrdtuIO1TTAk7LlBLGnXG0hXj9tgeuLOleOFiW4jem3fb6MBkAgxXTW8i7sCob oTtXKjkHezESUPK0cYrJKiqOvJhXIHMGQgUK+qaTDu91EO+zVP4Y+MzGJCTeZtGjcfvTL4cFJ/XT IHKWQwqI826RHzLwTSVB4KOK0bxNeeROSRZDFuhpPOYqWitmp2DPQj7g2CWQnqmODvQzecb014wx j+UncjIGZ72fghBv5q1hh/eBSD+yowGVso4wEOdb1eX4Xunp7U/hkSWccYUUlu5XIkmc+J5H+uPG WccQJV7K1SW8HqtzUAk+5AyuWUgM4w3ZB5a8oT3I+tai5ht3qVhA+Ij3r9nNDre2DH04/VJysOjH 1Fmun2dhpq8bK3SEfzKPiP8ArP8AaznMuWeQ3I8TsRgiBsjvrrVLOdz75R4bI43fWjWvjg4F4Fwm dv2sHCF4VSJ2PfIyDEhcz9xX6cACKaFxIBUMR4UJw8IXhQV/baZqCcdRs4bmg2dko/z5rxf/AIfL 8WTJj+iU4MTgBYlqf5cWFwGk0i4NvId1t5jyQ+wlpyX/AGWbjB2xOO2QcY/nwcbJoh0YPqei6lpM 3o38DRE/ZbqrD/JcfC2b7TanHl3iXX5MUo8018rXP74QmlQeS1pWnfMvJ9NrA7Naq3+ky1rQsdjg jybN+iWBaNWpya0sNfioaHFCxGofYZMckArnkUinTvgATakZSDQHbEtUjuv5KwqGHLuMFNnGCyHy fKttrkV5wV3g+OPluA9PhPHEAHYsMpqL0ttcn/R8iQDjd3B5Xd3Wsjn+X/IjUfZRcz4YADZ+mLqj IlhmqRrNHIsuxCklia178jX9rLMpFMYwPEwlCAgPUGtM1tO7hsERasTKlTT4hgHNB5Fm2nBRaKv2 a5uMQ9LozzVeChhyYhK/aArl45NRi7ivqswBpU08T9GFj5r0367UwEM4G3cqnf4T2IwWzX8gWapN FUUpvU+9fs4ejEiy0KcQzN9GBb2bCoGMjgsp6YebGnUqTsAOxqcDPo0ApJUGrHvhayLXbqBwoePj 44lsjyf/0iEL1Pjm8q3UxK6uCqZtAMxI+7JAUgi2x9mhO+ILEhwAL/F0yymPVaaV2wWq8A0pQV6n 5YQm+i2snOoPXYY2xaEfJqeGFaVFZVX4d69a7YhJNOUk/ZFSMUL2IdgBsQB9+EBldraNvU9epOIQ WwSu3H5YVXLRqkingMEtlju47KaChoK/d8X44a2UNFT9J6HIgrTlA6YeqgAbO4E7KNu/uTiyodFu 8ZodmOxrgMgx5OARRRiQe9N8lSCqAcl5DoOpHX6ciyCvGPTZfUAI6sOm2BJNFKfM2uzWcaWtkTDL NVjKDVlQbU5f5RzGzS73KwY+IsNlu9QnI9W4kc9uTn+uY3JzOALGWtCR0+025/XjZSAA20aBeS+F cDPhFWtbZAdjXxAONMW0+z4ew6YKVv0iTvgZA22Id6dsbRIU2YkFdsbYuQKu9MbbIN/WFQnbfvgp lxAMj8oaWJJnvJRVIyBHXu/7X/A5ou1dSY/uw5mmx36izcS1r2A6DOap2bauTiQlbLOkSF5CFUft HYYYxJ2DNKLnzTYQ1EYeVuwFB9/LMyGhnJrlkAQQ89BW4pa1PiWzIHZRI+ppnlTLSfNrXdyIHtvT r/uwOOI/1soz9mGIu2IyAt3HnSCGUxmzldB+0pG+Qj2ZIi+KLHxCTsERb+bNDm4o05t2P7Myld/9 fplU9BljuB4n9Rl4lc0d68Uo5xOrp1DKag5j8BGxb4EFpnAocQGRanaC5gaC6RZoXFHjcAjDG4m4 +iTXKAIYLrvlOXTJDqOkOWtk+NourJ/zUmdFou0+L0ZPq/3brc2m4TcfpY8L17xiJCFfrXN3Guji 45WW2IU79O+SZlCzNQ7dDkmqRpaDReTHbsPHDdBhxFTrzPSmRB4kc2zHtXJcKTFwWpPamShDiYHZ E6feyWNwsm5SvxDIGPCd08VimYweYrNoQ3q8T+0h6jMqOfZxp6YpNq+s/WQ0MNQjbM/iPbISn1bo YuEJRTYJ3GVW5GPuRVtHxljNK/EMEN0y5M1s+ItYz1NM3GL6Q6SfNVB3JI5D+U9MuayuUOACOi7A eGKwXBfjYb0AqKCv34o5FyITUvv4fIb4DyZA3zXrFVFLH7XYYLZALTxKkU3Xpha47uBKiq9cISdm oyztwA7bADv/AC4lHEXGJ0qWXi3bx+kYOaK2ttTUr2A+0caZAv8A/9MkNKU/ZHTN26y1pcEcPp+j JAoJ2poMKimG2A5tkOTSmEFkQS2FCildxhYuNAA1Kt45IBMi5zUqD36/LIxYyNlwHFSPoX5ZMMDt EtCNzRv2cgWQGzm77Ur2yYRIqrA8FbsSV96jrg6sui6JR8Q6N44pDX2jXEq4kU2PfphXo2oG7Dbv TAoC4U4s1d/5fGuELbZKFVKkkjYg7D6KfFiOarAAFJPUnbAeaOikSQaDxwheS4jlv1rsRkQF5uZC aMT17YUEbtqBWg29sY82yURSsisa0rQCtetMBWLFPNc5e8gj5fu44yQv8tWq3/BUzCyGrc/Eki1C nx65S5MdgjdM0zUNUuBa2cDzysOXGMFiF/mbj9lf9bBKQCEVe+WNRs+Ql2ZNnSq1+WxwDdr8SKVL VSykdNvpyRDdAtggDIlEuaxJG5YShfUA1+/I0qnK3I/DucNIbhNXAbamLKI3XSIEav7TduuAMpDe 2c+WJI10pAhruSc5PtKB8Y27XTyHCmTXPE++YIg28dFr66F+1t3w+FaZagR5sQvNdN3cyTSuAkUh WOH2H7WbrHpOGIA5uMNTZJKWT3EtyxdWAWu5zOx4OFhkz3ydHacjyLn5jLiGBkEfbQQxyBpbo04k KAaNXIShxCkDNw8kVJf29vxKSnknQVBP3HIQ01sJZigtR1qG+RY5QAR0IAH38cRpuE2y8a1CxvLy wm9SzlJFf7sVKfdgy6eOT6w2QNbhlOk+aor1vq0o9K5A3B/a/wBXNHqNAYeoeqDfHU70U5M+wzB4 XJ4rC5J0IoTsdiD0NcBiUCYY1c/l3q+oXzXGgwB4KkuGdY1Rq/ZUuRy/2OdJoNSZQ9X8LqdRi4Jb ImD8n/N8p/fzWsA/ypWc/wDCIc2PiBx+IpjD+R9+wrc6vEh8I4mb/iTJkTlQUwg/I/TAq/WtVnkI 6iONEH0czJkTkJRsmdt+TflGH7b3c3jylC/8mo0x4z0UJtb/AJbeSrenHS0kI/367yf8SbHjl3ra M/wT5RpT9DWn/IsYBMjqhjPmH8oNDvonfSWbT7rcqpJeAn+Xgfij/wBhlozS6+paDxzWtF1TQdRk sNRiMVwm4PVXU9Hjb9tGyQkhQQ819h1+eTb4mwqLGw4+2FEeSLs/txDuT8WSHNMxsza1DR2kYYUJ FR8jm4x/SHRHmvLMTUbCmW0xkurRCorwPVR3OKDycC3CoqFJ41Pc4sOjkNGUDv8AawlYGlTi0j0X dq0VR1xulrdY6BUbj8QXx+1Wu9cDKqDlqrcgOu1MVbJMbUO3h7f9dYeYYqwKharTj04nrt0OV9Wy K1uJ48BxH7RPXJArLm//1CIMDsdjm7LqwFpAruaYLUhVj4KeTCq9ckFqt22ZjxFftCpr29snS8TR iA6UJwsKWlm7GleuEFBLo1PLk7UVdx88IQBva9h0Zj164hLW6gUJpkaZGXc0TUgkVyQLCQtcxAIp uafEfE4pLhyCFhShIX3qcRzRa5EIG5qe5x5lLfwhwabAdcWTgHar8SV7VwKO9rYkiuT5NfMtD4So NaYE8lxJ47f24pKmaACv2ugxVetQOVaHpkJGmUQtbtvXDYSRTljLUblQd/HDFhOJO6KCIqMfUINP h26n+XBMMxyYZ5k+PUQp2YIF2oeprXbMHK52nNhLGpxIbYnbKnJeo+TdSsNL0QW0lY45+U1+8Z4y SUH7mBZF+JY2/b45XHEZm3Hy5KCU6lc/X5yyRrDCdo4o1CqF/Z3+23+ybNjwiIp1xsnbkxHUrcQ6 g6Dof9vMOXN2uGVCkIyipystsua3ivbrhu0NFT2whVwQChwEsjHZcIa79K9MFoBpoRNyIPWvXFs5 hntlFpkGkQNZHhJGv+lCRyS7Nv6saH7Cj9pc0+v0xn6meHPw7IeTUbQDkZV+8H/iNc1I08+5yzk3 tKtWOo38appcNxPyNGMEUjD7wmbLSaajc3GyTtLovInnCehTSLmrfzJxH0lyubXji4lJpZ/lX53l oGs1t161llRdv9iXx8UMgSE5t/ye82E8Zby1t1IqV5O5G1f2UUYDmHcy4j3phYfknIsqzX+rqyjr HFEf+Ju//GuR8byY8W6aL+TeiPU3Go3kobqB6aD/AIg2IymlJtHW/wCUnkqEqXt5pyP9+TNv9Efp 5DjKLa178t9COkzDRbNbTUEo8Uis5LcT8UZ5s32xgJvnybMc6LyG8aKrRyx+hqMJ2WhV+Snxyzw9 q/gcgyBkGSW12728bPsxUFvnnNTx1It3HSO0+K5vrlLS1T1J3/ZHYfzt/LjHAZcl8QU9U0bTI9Ms I7VTyYfFI/8AM5+0c3WHHwRp1858RR2XMHYq2BXpirRKr9ogfMgfrxtVqyxMeKyKW8AwrjaV+KHY VYt+YHlWDzFociqoGoWqmW0k/aqB8cVf5JMMDRV89KslpO0c6FWBoynbMmq2WMqRIRiK12O4p4ZK 22PJFWaVkjIHIV+L2yY5ssn0lm9hA8kMSxqCxACoo3O9M28CBEW8/I7t7lyKUNKEHxy/ox4lWJYm tpzJIElUAxL/ADHlQj/gcrJNhBKkhcLyOynt139snSArIy0rUKyj4Sd65EhPJp1AUS8ieRxvekkU bXt+9jLkgOKcUA6g9dx/LjyNMpcmuDAqdvbCgueNWoT9odfA4gopssqRmiip2B8MjSbpokqgZh16 e+Kkv//VISrM1QenbN06xf6QNGJNBtTGk02wjAKk9fsjwyQRLksZ+W7GgUeFT9GTaua48VAIcEkC uFK0A0Lfs9q4VpsMKbgnBaHKwYEEb++I5JC+NwCeWynt3+jJsRst3JJ9jgUqiBShJ65E2yjyciCl e/v3Hth6rELzwABUbnrhWXk0V6U7YpI5L6GooKAnYY7JPNTKfEafh45AyQI7uIcEFiKL2OTJRw77 ruLyEcV+LqQOu/h8sjxUyIQl3d21vHynIHhXrlcsvcyjFKZvMcI/uyCvgTlZmSN2Yxm3R+YkYj4V I77gZCz3szA9yOh1e1lpU8G7b7ZZHIQ05AmjEMnJKmoFPuy/itHDTD9fKrqj1O/FcwMtufpqS6QB lLAVHc5XTkDmyLR9RhkgWGRgOIoKnJwlwlxM8LR1zqVpaRkvKCx+ygoT8stllJ5NEMZYvPI1xO8z n42Pwn2yiRt2OOIApRZDXrkEy5reNBXCEAW7ftkk0VzMNqde4yC7rjMFArgRTknUyVkPFajfvitl 6/8AlnaabqGi3Ek0CXAjm9Ieqofoob9oH7XPKM1g0iurOYrCxhAENtDGB04Rqv6hmNwhkZFX36dv DDTFvCrmNSN+m2BWq7n7sUt12p8sUOO3Xb54bVSe5tk+3Ki061YZEyCqJ1XTV/4+Y/oNf1Y8QTRY j5l0Lybrkv1iUzQ3wFPrNqhBP+urr6cn+yyccxjsGVlIYPJuhw8a32p3MYO0QEMNR/lP+8YZjmMC dwGZnJk+m6hY6VEYNN0wQp3keTk7f670Lv8A8FkogBhK0U/mTUCPghiSvQtU/wDG2HiRSi2u6s2w mRP9gNv14bZcClJquostWumFeoU8f+IheONsuEBRBvLk8Wllda/ZLs1PxxJXgCaWmlKQPUqR4HK7 tiQAmaafbAfYH3YRFjaHurPUoAJdMuGUp1tpTziYdaAEckb/AFWywbK3pGvx3z/V7iP6teLsYzXi SNvhLf8AEckw3tODiUvEvPPlb1Liee3WkqO/HagZeRPHM8AEBrvdgdtI61gcENWgr1BGR97fAprY Rn1lCeNSBhB3XN9BegaJdXlh9WmhtxJIPiVHFKjcbZtZxjKNE8LoxYqvqW3ctjNLLJGrRThm9VDu A9av8X/GuWwsCvqYDraFPGMcmqzVpxYZYrRI2XY08N/fJBbVipVQ/MJz2A7jIhStBEaHkOfZa7fh iRZVdzNOLfDUAD5DpgpMi2B8LE9NuvbJKFrMGUAdtsjSVPiWADHia0pTCEELyzlVjB5Adz2w0Ff/ 1iGKhYsvU9jm5dZFe8ikjluTtt0rklJbBK8gRxAHxd65IBTya6qDwBHvkrY8ha0qepXiD0ph60xl 3rg6iqtsO2BJktO0nJevY4aY2vBUufGnfCRuyDqE7lQtPDAeaHcgOu1emSQrF1+zT9nqPHFNrQxI Wg6HEJapSgC0Yb/RieaAOi8OCuw38cBZk23yK0228cjKQCi1GW/ihU+qQGPhlXiBsFoI6xamoQ+p J2C/FT50yHiFmMSotzfyHlbWM0rD7Ppozb/7EHKTkvqy8MpI/lPzlqc5c6ZcsSdua8AB7epwyqWe I2cqGIBERflj5sdgskENszGirNPGpP0Kz5UdTFPCs1r8ufMejaf+kLn0ZYQwVhbuZGFe5HFcOPOJ FBixuGeRXoWNOhrmXjn0a5wBegaZN61rGeQqFFB8ssjPmHG4SGM60qnVZi5rSgplMzbkYBtf9JBH jxKqOvbKnJWrEeIUjbvvthvddqaMaCuwXj3BJ6fPDxFiAGllj7sBTAltpYz8XL6BucU0sW6hANd6 dvHIrGQAXxxSXCs0ZEaDuxp+GTAYmZPJwsYus10vyG+SoIAJXraaaPtTM/v0pkbAT4cjyZFonlOy 1Cya4+EnpEksphBNT8bFEl5cf5eOUZcougkwI5vRvIlta+WNGexuphLPNM05MCSsoDKiBaui9OGY 08gkbTwlkLeY7AGirIzeBAX/AIkcqM14So/4ljP2LZz82H9MTJeFTbzHcfsQR/Szf0yHGyjC1E65 qLdDEnyQn/iTZAzLIYwWjqmot/x88fZVWn/EcgcpZcAUmu7xhRrmRvm23/ChcjxkqIAKT9K8izeL Gv8AxKuNklmIBTaNFIZVXl4gCv30yQtRELS1QagVPXJgIMhyWcPDJNbQ2OKx2LfAmmG0S2NOZSSK dj1wpIpria1w2gq8FnJMwAG22RJpkTyT6009UAJG+AC2EpWmCRADpkxFhaoFGTAVdxxQxTzLZehd x3cNVDmrU2+NfsPk4pT/AEa9N/p0Vw/97ukv+uuzf8FgPNDH9Ysknd1K1LFiD8mzKxSoOPMEGw8s 82+WXjka8tk4sm8qDuP5hmRIAhljkk+j3NZYyoJdPtd+uViLkZJXB6dp/m+6sLaGGwtI34IFJnBc 1FTVfsnvmwOmE9yXSjIYyNDiSq6nlvLqS5uAqyzMXcKKKGP8ozLhHhAA/hQRa4oHfgAeJJNa165K 08K/eEekjfb2Yneg9sbtgYqQUl2VdyD17U9slaAFzIBxHfqW74LUhVER4F2NVrRWwWhpY4TvKx5g /AANmr1HL9nEk9EuqWcsq0T7Qqew26/tYGQK1FPJqEGu4JxtlINj4XBcfa6HHmx5P//XISengemb oOtlsWmrWg+jJNci3vXc+xOS6ItfRpN12Ud8QzIJ5OaNgo3qO2SHNrmCA2nD4lO225675C2QAaqi kbbkbZYg0Gw1TWnE4ebHirdcX5bAVONM+IFwjLAgbEdcUUuVGRfE4AkQoLkJrT7JPc9MKk0G/Wke nNePEcV26jFQW4kZnWKMVZjQAAkk+wyvJMRFtkNzTJtN8lSXQEuoyNFEfswx7OR/lk/Y/wBXNTm1 VnZzY4u9PrXyj5btgPT0+Jm7vIvqOT4835ZiyyyPVtEQEzjsrOL+6t4kp04oo/UMrtkqMxC1GRKq Bd2YKAW2qfAZA7pX+gOJLMWr2NNslwra2ayt7i0e1nXnDKpVlPvkgKQXknmr8ttQhmaewt3uYSSQ 0A5N8mgWjZmYs1c2JCT6boPmuN19PTLpApoRJE6A1/4y+muZJzR72BgCuu/JPm65uXmltooA25Mt xAm3/IzKpZ49GcYkBuP8vtUrS41PT4Qe4maUj/pHifI+OO5lRRcf5e2o2uNcBB6ejbSNX5PK0K5E 5+4LSunkHy4v99d6hNt+wkMYJ/2UkmQOeTLgRsfkvyjGV/0K5m23M1yFB/2MMSf8nMj40ix4UwsP K3l8zBINHtVHd5TNcU/2MkuROWXeyEU81TylaWmiXlza21qJVgdoxFbQoDRf2WZZHH/B5GEieaHj DaHchqPLEiDY1f3OZgmtU2NJt4/7y8iX2G5xMvJnHZeLDS+QDTu5O3wLQGuAEokS9c0fVbGDynaW unqyXAX05BKAHXf43an837GYkxvuiiVBSWFW+I+LbnKizBVF6UwJ4i2ST/Ztii1wJPXtkSE8Rd74 KZjkuBqMjTWSXcmGNBnG63Xuvw7dcAG7HiKnVgdzvk6QDTqb175IK7CkBqgxYhvFJ3XIpYUHXtiV O6YWWmyyFWcbYF2pPIbRIwABkxFrJRISmTAQuAwobpilvFSlWuQrLbEEdNx9GN0kIbyoR9WuVGyr L0/2IwnmxQ958dyo5UC14j5nfJRlTLhFJVfWP1iNwV+KuZkMgDhTO7zXXNFk07UBewjjAx/fIuwB 8cvEbLIzoJ/pJt7mNGecQxsgZXKl6mh+AKpX7T5mmcgBQ4nC3BcaodqEeB3OZLVZtUNySBtxI8B1 xpnbnb94NuO2w8cIGzE8219PmvFyR+0B2OJtCsnF3IWrDYce+DojqqzxhVAqQnRRgiWVKJKbJUk9 96dckxNOPcM3HagXrtSmRRanvvU0p098lTKyVzOoNOu2ICTIci//0CGgYmv+xzeQ5OqkQVyRc24m gA6ZMhiArx2tSN6nsO2PCy5IhYuIOwVT0J3NRhZKEknNmIG69aDbbFrKmU51dd+5Ax6pIsW2qAIG Iqe/yyRY0t9Ou42LV64p4V1G+yN6AA4AT1RXc0FNDyG3h3wpXliaBflTEBJK4fZ48d/A4VrZe7Py LyEnpyPtkeinZmXlTQ444l1GdeUj7wg9FXs2aXU5yTwh2WPHwsjmube3UtPIsYpX4jTbMFttAv5k 0ZdvrHIjsqsf4YaKg2h5PNenqPgimc/IL/xI4QEkKD+boz/d2jE/5bgf8RDY0tFQk813p+xBHH7k s/8AzTjSaUH8x6swHExoP8lK/wDE8aCKUW1rV2BLXbgHsoUU+5MaTwqEt3eybSXczj/XI/VTCmlD 0RIfidmP+Uxb9eJKeTf1aNW+yP8AWAwcSkNiIKKDG0rxHUbdsFoKoIxT3GRtXUOEJC5JJ4/7puJ8 cKRui5dV1Ca0mtHdPTlRo2+GpowKkqxb4eWI2YGIYrH5O0hCCyM9AAOTk0A2GWnNIs4+aMi8taRG Ki2So3BI5fryByyRQtEx6XYxGqwKCOhCqMHGSz2RaRRgVVAP8/bIEpkLGzYWmBrXKDWvbFV1aZEx S7f6DkmUTS9U226HpkGB5rlTjX3GJS2oIFMFK0/2cICZClvBuuE8k8JXg0HywALwlsmnXFBFKTbm oyTFUggaViqfKuAqnljpCRqC4qeuSq2JkmqRKooBkwEWvpkkN0xVumKuxV2KpXrbcYG+WNboI2Qf lNiY73/jKD+GTmN2MBs1cRhT9ZJAUGjBhWtcMI2aTOVRWLGk0RlBBZCagbD6cuIo048JcQtIdY0y G8t5eSfC60anWhy+MqarYNpKPbtcWDVJtpWQfIn4c2WKVm2nKmlGYK5NSNvlTMoNPRtfTDVYVPgS R+rCQoIcTVlKb+IG5GEMSV60IYLVT3r3GApBCMtIkqhRirDqtNv9bISLGqbvXJmMb8l4/ZWtafRg gNkwKGjB5L2I3JYbZNiSvZxI7uSodnqEGwpSnTANtkB3PlIy7UO4oPDGmfVbJF6YDEjffbfEHdJf /9EqhtyFq2/yzfCNOqjHa1X0KHm1OvTJqQ2JPtcBSlMKg2sMpYUpuT4UpkVtZJRSGQ0NainfFBcX dv2t8I33Te1LgCW28Kb9K4lA5reSnZtmHTCm2lIHwgnfvgLEKqgKC5NSNjiyCxVLNyG1NxXCCx6r lrUmtSO+FlyCK0y1a8vLaCp4yOA1fDvmPqJcMSWzCOIhmuraxHYKLKzAEyqANtkXoB885/nu7IWS xiV3llMszGWQ9WY8vur9nC2VTSmlabV8Nv1Yo2XYq4KKVxS3QYpXDfbAxcVIFD3/AIYsiuADbkdc VXhFHQUyJYyXACtMDItGmFVwApgCtgAYaUh1Bii3UxZRPV3EZG0O4jG1XgbDFFt0ril3E9umBlxO VORoMJQvETDBat+kMbtVxjY0p2xWj0bVX6BSadcCqiwTN+y1P9U4FXizuTsEJ+g4WQpVGk3TChWm LGUrVV0e66Gg+eGiviKy6JLtVh92PCU+IFRdCTbk5OHgLHxFdNGt1Pj92HgYmVouGyhiHwqBhEQh WAAybFdilrFW8VdirsVcDiqU67/cMMI5sSUJ5TBC3vhzUD/gclPmsTsuulLRRxupKPKoHuCctxHm WnLvSK9CCOJxGooa8wPEDIEklPCAEqdR6bL4gj7xmQ4sjs87uqQ+Y9RVQdijH58Qc2en3DVOVbq/ Pq3Yjvv75nU1RNrJHDMDSvyyTWTuqmhTl9mnbI2yXITQnrXofH6MSoTKEp6Shd3qAT7HtlR5pKy8 QrM5k+J2pR++GB22YjYKUn7wKAfs7t8skNkx3U/jZgioaHt74sjbvTCVcEbfCR3w2wd6bq6oTUEA 9T3wMg//0gSy7cFFPYf1zoS6y1reJO9aYiS1bTlKfDuRtX3xQa6NwqoLFwOh67YCVipcaKCae1Om JYhw+BuleWEGgpO69vUCAHZG+IDr7V/DG7VZwCg7b9a42tNilNl4nuxySHEKy0ANDuSfHK0qgoFA G9B0PQ4eqbDvTanGm/U03/VhSAmOizLZ34uZDX0lcqvixUhB/wAFmHrPoLkYAvd3kkeVzykkJLH5 5pXPDuJ8MQypdQjtiimwNsVb4+G+KQvRTTcYlkuKGlKUOFSG+AAHI5FWwB26Yq3Tw3yLFsAdzQ4U hcEXgS249uuRV3BewI+dcKF6LtTx6EjFNFsxt3IPyxtQ2IGP7JrgJVettITTgfuwJVBZTN0jY/Rg QrJpNwQT6ZJ8DjZTIhVTQ7hhuFX23yQtjasmhS0oSoH048JXiCsuggGpk/DHhKTktVXQ7cfaJP04 eAseJWXSbVeq1xGNHEqDTrQGvAZLhTxFVW0gX7Maj6MeEMbXiJB0GHhCrgoGGkN0GKuxVvFXYq7F V3bFLWKuxQ7FLhirsVdirhiqUa6R6RrhHNjLkh/KvH0b4g/7sFfnxyU2MOSKdHaGAqByV1YV7Co/ hk4FrygkClATcFkjc0aRmEderEfE1MsIaoyPDJBhaoabmmTYAPONQ+LzNqpB/aXf/Yrm00/IONkR KRBofULrX7PCp5Efzfy5l3u1ALQ1CSF22rk6Re68CpFOnfFlTgSzA9Kd/bFrO6bWgibgCF5A15E0 rlE7bJFD3Du0poKiux6jrk4igq1AwlqlCW+GnXE8kgOqI+Sh6ODSv9MatPF0WCNiD0Ibfl323yVs QF6kOOXQ+GQLK3//0wMFNzWhA60rnQy5OsiLDnXku+5r8tsiDS9FhCgVHTJMXM6V2FfCowGK250L UIpTw6YhNKfHkTUnrRadjixpU4nma7KB08cKaXUKnwDduuKWnBNCD8S9D88KGkVCf3mw6jBJQuBA PSqdgRiit1SN6HklVoKGn68SzC9I3SSjqVP+V1I8cwtXvG3JwfVSLUbA5pnPgOq4E1xSeaso5bYK QFTgBtSuKlsoANtvntgTS5I3IptXCSlUFrM+3Bqd9sSaU7qi6bcn7MbfTgtVdNIvD/uvbBadq5qy aJdk7gDFhYV00CWtWYV+X9uO68Ssnl9abv8Adgoo4lZNCgH2mY/Th4V4lVdFs1NeJPzOHhXjKsmm 2a9IxjwBHEVVbaBdggGHhCLXiJB0UDDS2uCgdBirdBih2FXHFXYq2BirqYq6mKt4q7FXYq7FXYq7 FXYq7FVx6DFLVcVdirsVaxVvFXYq7FUk180SnjiDuwmaCn5WFLS+PjL/AMaZOe5RDkjY5oynpqT6 kaq7KRQ8SNjkgFPJLb+TlqVpFTjHxldG7F+B+L/Y5eBUbccbmlMV47d9vvwsXmt5X9Paqw3Pq8SP kq5uNNyDh5v0K8a0rQ7jcjMynGBVYf3h27dfmemA7MhurLE8zpBGo58uAI2JPuxyN1u2NoimjBBT fZtz1p0+YwWxR8CoWQ8Qd++VyKnlanM5R5Y+AZ3p8R/Z3/YphAuisStPJAjIAjEFeQHWn2icQztY 8KOwWI1AALE9v5sIlXNjzXPEYz6aUYtty8CPtYg3uyCoyRhQsZIkH2gd8jZUv//UDQfCpUbFu+b5 14pZIDQKRQjf54Q1tszcORX4Oh+eFbU+IqCBQDp7YVDTK/LkPsjt447KbdEK8qD7O9T1OAqF1OS8 qbdThVbwNK12wo4S0qmpNemKgLqb1G7d/CmKrtiOvI4Utr1VSPu64FRADtIGkNSRRanccdtxmu1h qAcvCN1dagbnNU5wNLh1wJHIoyyt2uJ0iXbkdz7ZGRZxqmUx6HZhRyWp7nAAWoyRA0uzH+6wT74e FHEVVbS3T7Maj6MeFFqgijHRRhpbXBR4YaVugxQ4DFW6Yq7CreKuxV2KuxV2KuxVumKu4nFW6Yq1 QeOKthT2qfkMUuKsBUg0+WKuxQ7FXYq7FXYq7FXYq7FXYquPQYpW4q7FXYq7FDsUuxV2KpF5hJ47 YQN2ufJ3liv6Ou2r1lbf5KMJ5rD6Ve0kdrmSMg+mI4yC1KciPsr3/wBbJ9EWhmtyzx3QClw8qni/ NOPFl2/y/wCZctE9qa/Do2FEUC1AyTQ8znJ/T2qnt9ZIPyzdab6Q4mY8kWqqKsBRmHX+zMppAXJE UBC9W6keGJKapcC+y1Pt9OBMbVxHIUDcOnQ9jkbFspDZNYITSPjUkgliRsD88x5S5tZKFuWVJht8 YqT7bZZHcJQ/JqgN9k7j5n7WTpIbDcfsAge/v1pgIvmyiqLxADKKHxwJC8cgVeg67jucCdn/1UIg GJ7oO+b8usWmjV8B0xBSRssUN6ZWp4FqkfLCwiKDlqGBIBp0rhZOO1XJ3JoBkRuWY5LRQrUjfJdW DYY7gfQfAf8AG2FrDvtemEYsSDzFKCtcFMySVRYQFLllUggfEwHX2xtVjJ8JblVj0p9nFADYUBSB UMenzxKa2bDhFA6uf2u4wKqQhmk3NWIJJ+ZzXa3kHN0w5otVqM1ZcxdTsMDO9qTTREP1+I/PIy3Y mNMyGSDW3kkOxV2Kt4q7FXUOKt0xV1PfFWwvzxVvg38pxSuET/y/ecCtiBz4DG1Xeg3iPoGNquFv tUt+GC1bFuncnG1pd6EY7V+eNq2Iox0UYLSu4r2AGNquGBXUrsd8VQDDi7L75YEOxQ7FXYq7FLsV dih2KuxVc3TFK3FXYq7FXYodirsVcOuKpFr/AEb5ZKPNEuTXln4dGuCf9+yfgoGMhuo5KSXkcWoS LJIB+7QCuwUfD8G/2m5fFmTHGTFw8uWirQqPqvqEMlDMxhLBuXL+Vh+z+0mCXNshK42h9yhp1yTV IWHmho+taoT0+ssfuObrTD0hwsiOS4uEHBAqxHYigr/supzJ4QXHEjfk5ZnL0Y/hQe+EhnxK0jGN l4OCpHxcRuo6BWr/AJOQG7PiXRGRl+NiVVaIB8++JWJKYW7kwgPyPhvT6MpkN2NoW7ki9Vq16ZOA NLxFUiRCgDqeWxHuD0IwE7qF6gpJxC047ry3rT5Vwcwytd6IjirMQrkdPmfDBxWdltSLVXlTpsPo yVIjs//WQZCqjg23WgzoHWL/AEqxCViAhbiQD8VaVrT+XAyPJTNOHt4jCxWlUDb14kVQ+Pvjar5I 5CoBUEhORK9AK/tHBHmm2jA6xfEB1rUkVoenw4b3Rupj4QSQSDsMkxpofF9on4SF+jFNLmMfHiil WAo7E/tVPTAvRrkXT4jyfufbFEeS9F2p+HcDFkqCKMlaH/WJ6D6cCG4wBK/E1CigPjmq1hsgOfp+ SJAzXlyl6gAbd8ChONBWt4p8BkCmRtloyxqbwqqCFhTxIriq8Qt3OC0t+h742q11gj/vJAn+swH6 8kATyYGYHNesURAK7g9DWuROzIG914jQfsjBaWwoHQDFWwfkDireBLsUN4q4bn2xS2fDFWxirsVb wK1irsKtnbAqBk/vm+ZywMWsVdil2KuxQ7FXUxV2Kt4q23TFK3FXYq7FDsUuxQ7FXDFWP6+4Bb5Z KPNhMqnl6jaFNTu8v30GMuaQdkmvhI2oTLwMtFhQp+ypI5Fj/M3w5ssNCIdXqRckTpk3+iLFJKJZ aTCN12FBTlt7KcjlG9s8MifSiI9xTtlRbAXmIdv0hqRIqpuHLfPlm8wDYOBlNJqqRywxlI6lVapX Zj/rH/Jy3kWF7KaIGX4jQgVHvXCU1svVFNCDxZTyLeI6cRgTyVuLV6gs2w+WRtmSmNsg48W7DKJl qlsFGZYVmJZQ1fs70H05MXShUSVQ4AqXpuvag6UyJDMKhmARZkTiy7FTuAR+1X/K/lyPDvRUi0M7 KyMAalzVyOnyywc00tVSo4gBf5T2w2gv/9dpVRyQCvD9rN8HVrKkLUHmD07UySXbFfiVdttu/wDr ZEx3RSiWflRae3HfJAsgqcZAKDb+Yk0r9GAoDTIeHSrFjt12/wBbCChaqSkbn4B2OFWzHRqihU98 bVdwCrxYgKNyO5+WIS0skYBKx1qduX9mLEOE7tWoIC9FFAMFIA3WPMX4qQAvtizJVbVD8WanWn1u w0wqKMXbrmC5KIXcDKymfROPL6/6Uf8AVwEbsSNmUZY1tjFUSg+EffildgVCR6lbvftYivrKCakC hp2By+WEiHF0cSGrhLKcQ+uKHu49MMdybgBhFQzMVBZeXTi5yePjuNfxNWY4jGXF/B9anNfLZWMH 1KFvTaURqGFKg+HL+fJRx8cjxfzWGXP4UIcA9M5xgq3OsrE8gWMMtvQzkuE47V4qP22GRhp7A/p/ Qyy63hJA9Xh/Wu/SM1xK0ViisVjWVmkJAPPdUFO+DwhEXJkNSZzMYj6I8X+nQokvzqF46MIXjgQu rDnQgM1BvlxERCN+rik4wnPxMhB4ODHBNdOne4sYJ3+3IgZgNhXMTNERmQP4XZaeZnjjI/VKKJyp vdihcvTEpdirsVdireBXYq7FXDCqAb+9f5/xyYQ7FDsVdirsVdireKtYq3irm7YpaxV2KuxV2Kux V2KuGKGPa8dz7YY82E+SroXw+XWPYmQ7dftUyR+pJ+lI9TnSC7vH5hSJLWoBA3YcnWh+0/HNhhFg f5zrs/Ov4lfTnLMtUHxJPIWXpuVH7tvs4cw/3q6fYk9EUSRSnWo/XlLN5rHU3d+eo+sSbf7LN7g5 OvzcyiVJ50B4knYdMvaUVJI1Vjbf2GQAbjJXLRyBUVeJHU5CiEncKggdmop5KN/DbI8VKm1mkYQM F5Gmz+x+0Mxpk21yUJqGX0ljKry+FWFKACinfJjlbISaW39F2Z25EDZV6/f0x4rZWocmcmnDl+yv Q/PJ8mQK5oCnEOwLsaq3h7YBK0grkdVZSeHwsCQ4BBIwEWxkH//QYgIBUiq9vb3zfOsVYo0RCJFB ciooevyXrjxIUQFJcqAVXx2xtLRnY14BVrtQCnTEBVMhxu/xMOm/TJI5FoB5AAorU4Vb9MglT8PZ j2xJVbRVAANVXoMDERbETSPUqVPh3w2ktGqEL4GpOKRzWMwFQPsnoe+EDZF7tUPcgjscCUZZfFzz Taz63Zac7IxF3ocwnKAtXVe3hkES3Tvy8tZ2evQUpj1RI7MjybU2MKopfsj5DAlbM/pRPIByKgkK N6nwwxFlhkNRJSKTTL6K4sbxP3skbkyKq8SBJVnqa/F9rM8ZomMol1GTS5Bkhkj9Uf7z/PRNzp1z N+kQqgfWWj9Pkeqp9rKoZQOH+hxORPTSlxj/AFScEXf2UlxFAsTKrQyI4DfZPEdNsqx5OEn+lFyM +n8QRr/JzjNROlS/WZZY3jCXDBn5RhnDUofTZvh/4LJ+P6QD/A1/k6lIiv3qtJplZnlimaL1FVJV UD4gu3h8OQGbaiGZ0w4uIHh4vrVotPgiaVlr++RY3BP7Kjj/AByEspNf0WyOniCT/qitBCkESwxi kaDio67DISlxGy3QiIih/Cq5FLqf2Yq0XVFLOQq+JNBiq4YpdireBXYqk15rdxFcSQwRRsFcRIzs RV6M8kbfy/Av7t8kAqK+vA3kduJUDF5AY+J3VNvtn7Mi/wAuNIR+RSgG/vG+eWBi7FW8VaxV2Kt4 q7FXYq7FXN2xS1irsUOxS7FXYq7FXDFWOa83xMPbJRG7XIq+jbeWqnaolP3s2SG8v85J5IDWNMSe ZZECozhGd2XlXh+p/wBnnmbp50HXaoEZAq2enfV7cvxMZWJlWEmqjm1TT/gcjknxFshDY/0loIYd adP1jHkwBt5zaAevddy1xISf9lm7w/S4WT6kxVmYtTiUA+Ko3+jLaYHctryVuairHocSq5lIGzLv SoNRU/tb5G02qJyAqwrTcA+ORKSnkU8yxrCWYKFFDt3FeuYhiCbazuhLiad5m/esyGgNe+WRiK5N kAOapHbkhgp+Lty6YDJZSUXPpr6FFLEVZ6bg+HLJAXumPNavBjvuQNsPJNreNOfT/JFK4bZXYf/R eWYNy4g9gAKUp345vqdYFKR29QO7fEehHh0xAQsMQpyLUUnp3OKXBUPQE+4wlW1niiWQCIOzAUkN arQ70X7J5YCCghSZyaBT8PcjYfdlnRXLHI5UR1LGtOO52wFW44n5cea8tzWvXBajk2t00Y+H4uoq 3b/Y40qGLszElianrkihzJVhv23xTVrigK/LAU0jrPZTQUr3zS6v6nZacbItD1r1zCLlRIVh06/T kWJ5p75cQhnJw9WMuTIBkmtcMKokdBgS3gVbLNHCheQ0QbEgFjvtsq1OKqa3kDiUqxPoishKsNqc vh5Ac/s/s4q09/ALNrtKyRL/AC998VVRMCivTZkL9R0ADYVUkv4ZrKW7t3V0jVyr1+ElF/a/2WCk rTPdKzScg0R9IIgQk1b4pPiFfhof5cUIaG41OTSZZzHIbtiWjhKiKRV+GsXxcV5p+84SYaUqj/WP qNtFKzNOOHrSeosbr4yMOS8/2V9PAgrtJQRRTwclaQSMxQuruOe/71owB8TcsSlWlsluLSO3m+EI BXgSNwpT4W+13xVFoKKF8AB92RVdil2FXYqlsWq6RNqs2mQUkvkHO6KRlkQj7AmuOPper/LHz9TJ cJq0LNS16Cxu4dPht5r3UJxzFrbgErHXi087uUjhiH+W3x/7rwiN7qmwytUv/bb55YhvFXYq7FWs VdireKuxVwxVzdsUtYq7FDsUuxV2KuxVoYoY1rv23+WSjzasiK0ug8sLXpxk/wCJtkh9TP8AhUfr AuYlA3ljO4HQr0IzIjHhLh5xxAd8USzyPbTu68RSkYOxoPHImgRSwJMZEjhS0kKKjpUfry0c2kGn n2m1b1mABJlkJJ/1jm8xfS4kzuUcsfHkx3U1JpttlhLUEUkbrbmQFePLgVDVcEjkr0/33+zlZO9N hC+GBmSq0JFNqbgsBy+HIykquvpIGT4nFKOwpX/gT2yBsp6Iy22KsSAx7Co39mOVya5N/Vh655Gn WnsTg4tlvZXk2WlByAFT2qO+QDFL3jYxlmAPJuLHsD/Nl4O7bEqYVg/p/CCvw/Svf/ZYfNVdI/Wb tVeoHfIE0m6f/9JcW0gQgMAtaGm42983plbqrUpYoF4/GKg1AwgpCnII+ZeQnifioB2/ycIKVssi MgKAqOgPjihSogBCmpPjhCWxGftnoO2ElSWzNwhVUNGFfiG3XtXBW7FaCvpcd+devtiyUiQdvuyS FvA/2YoK8UpSm/jgLMbNqSdsTsxRtpX0wc0mqPrLtdPtG/5yMjAINcwy2BVC/Dt2yIQSyDy8K+q3 viOaZHZPBk2tcMKoodMilCXuqWVg0S3TlWlJCBVLVoK/s4aVL7rXtPngdFMygRJOHCKTxYqoAD8l +LnjSCh/05a2jX6LDJK0DxxOZGUVDFY0VWReXFPU/aw8KS02qxNGtotqiQ3MctxIodweQMr9UKN8 bQ/F8WNIUV1ye41DTLd4ICjxRzNVKlS6O1I2avH+7XGlvd1vr9/I1mCyiOW3lmlVVCglGcJ0/wAl MBCQCpabqd/MmkNPcyO0zyPJQ05AAcQ1P2VxUIEXNxc6fCXkck37jdiSVDbCrFvHDJVWNqalqBG/ 736f96olp+GMuSCU+8ub6prTDp6ygfQGwSUG2QUyDJvFXYq7FVC/adLG5a2FbkRSGEAVPMKeH/DZ KPNBSnyUbFvLdi1mwblGGuTWrm4b4rv1v2vW9fnz5ZPJfEgckkjm+oef9QN/qv1CO8MElrbSLGI7 qNYhD6aXMo5o0M3L9xG2SO8AgM56DKGSXjck+JyxW8UOxV2KuxV1MVdirsVdirmxS1irsUOxV2Kt Yq7FXYqxjXHHqyCnQZOIapHdGWO3laP3Q/i5wx+pnI+lKYWMZqDvWuZh3cE87TJrsSWrRv8AaPhl QjRtt4wY0gq/ARlw5uI8+0xCYWYd5JP1k5u8Z2cSaYohcD9onZeXbwyZLCtkUiGKNXcfESKUINad RlZ3LMHoVRrliwSONYa9QnifGuREO/1JGzUa8zQkNXdxuBXwxOzIck2hlJCxmlF+ySOntmNIdWqQ VFmjBq61IPXI8JRTpZBITtU9z3xApihPTAb4TTmwBQdwd65ZbavaOMsQKI9SWLe+AEqCorLbKSUj LHoW6VpkzErRf//TUYyU+J9+qqv2ffN71dWhiZORKmrdx7eOTPJLbyMwqxPICi13wAAKpLXoTUDc A++SpQvfdAiCrHv7/wAmAc0O4SQ/u3WslKsPDwxO6huMcoyXI26JTEqFElQ3zySVNl32xQWwrbN2 GxxWl44hSx6UwJtyU+1SikZG7VMbZf3Ipmj1R/eF2eP6AiVXjt45jNwVFPXBSWSaAB6ch/ysEebW U3yxiuXqMVRVDkUsY83Mou9PVun70nxoEHL/AIXJDkqTIjmGVONStpaxtt/M0TfwwqvdWddUZQCz 36qV8ViYSScR/kBPjwhPFs4c2mhlQllhsWBIFQTL6yoBsf2jiWPP+qq29nOdUt54x+4s4kgmJ+Fg 8UMrNQN1X4l+PASKWlkCMiW5Kn9zZSoVArWQM6PGrVVfg9T/AJ6/7qwFkr2UEcBsRNKE+olkjJoB Kjr6hlTk3+6+HGSPAgK+iaU031e2nbjHG8k3NRUSOHP2XrxWOi8vi+PEpKeReW9Ojlll/eO87+o/ JqDkXE3w8R2kXAShHWmn2tpJM8CFWuG5ykkmrfT064CVRWBLeKGsUuJA7gYoaMkY/aGFUtttH0G0 1GXU7W0jhv5wVmnjUqXBPI8wPhZq/tZImRFKibhbC5CrcwpOEIZBIiuFYdGXn9lsAtW5LkuOKCgP UnEBVKlNskrsUOxV304q7FWxgVrCrqHFWxirmxStxV2KuxV2KHYpaxV3jihi2t/3sp9jlsA0z5o+ EBPK0P8AxiU/e1cEfq/zmeT6UnTc17dszHCKoZOFGP0Y01nmtkYBGp4H9WSiEMD0lSYBvsZH2HXr m6x8nFkE0JMXwFaL2B75Lm1tqRTgN2JHw/8ANOApHNXYRhmpWrb1PXpkBbI818TMVWMH4f2Wpv8A LAe9N0mVvWgVhxI/a8cx5NcivZo1cFdyOq+GDemJJAXyM5i9SgDdKU6jIgb0gIQBVPKtHG4Xv08c sLapvyLHmanr8R7e2SZU4hS3FAQKDr1xQ//UpmqOVNj1X5Zvq3daCps7bEL8slSFL49yRSu/44UW 2BX6MDK7XcW+1Tbx8MIKGm5qxYNViKVxq2Km3I7nc41SVxAWhfY7Gnzx9yRzaajMQuyjpipbpRdt qbE4yRE7NcSRUjYfqxKQqqSCgJ+Ab0O439sgWQR8IrEPnmh1H1l2cPoirjoBlAb5dFSnQYsCGTaE tLdiOhbGLCSajJsWwaEHFKLqOvjvkVWtDE7hnjVnH2WYAkD2JxVD39pLcQqsD+lKjc0b9mtCtHH7 SENiqWzaLeyty9SG3NZHHAFwslR9XkC8Y+XGP+9/y8OyoiHTJ414fWkWJeASNUNAo+KWLd/szP8A Ez/3mKro9Lt0tXt5Lh3Ry/IgKjFXVkCckH+61b92328FKtGj6V+20shPAktI1S8f2Jfh4fvP5mwq rx2mlRKVS2XiSWoQG3avLjy5cftNjutr4Vs7fj9XtkjKrwUqoBCjolQPs4qrfWm7LgpWjcy+AGNK 160x70w0q3nL/NjSHVc9WOKtUJ7nCruI7nFXcV8MVboo7DFXYq2MVaxV2KuxV2KrsUtU3xQ3iloY q03XFWsVdirsVdih2KtYq7tirE9cIMsw70y6HJqluUyXbytbjxhTGH1pn9KRxii0PWtczHEKryHJ D4dcDAmltxLyjkNaFVNPlTDEbsGCaX/vGOIpuTX6c3ePkHDydUxFfSBbem+T6sByRqICGCNTioYb ftV8e22UEtgbMZ5ijUBNR32674grLkqstWqhLMPsj3wLeyOiJUemz1XiCO4B8OOUnvayq1VgrtsV 6+GQqkKxrIOS/wByv7Z+zXIcv6ygd6VXR5TSV26AU61GZUOTaOTfxK6K9AaV3+1gVcAyHcla7im+ /bIndX//1WEAuQdx0A/jm+t1lNyLKaKTsuy/L3yQQFq8o43AIIcUYdSd61yIG6SQ0UATlUFuwwko WGRqiPeh6+BxjzVdwTlv0yaCpbhtjsTimqdIR0+VR8sVK2or0pXwxpW6NQgE79MB3UBeGJ2P2QKU xS2xQkCpNeo8MFMuSZQKDEozn8/1EuzEbiB/NV1QeOY5LMBWVQSMUk2yXRRS1+ZrhixkmYyTB2FW 1eRRQHbAlvnIerYoa+LuxxV1Pc4VdxGKu4jwxpLdBihvFXYq7FLsUOxVvFXYq7FXYq2MVccVdTFL qYodTFXYq6mKupirsVbxV2KXDFQ02KtYq7FDWKXYq7FWsVd2OKGI62f3sh8dssgWuWxTKU8fK9tT /fUeSx/WuT6UlQk5mOICvHLFiQsuhxtpmHXgx/A4Y80cLCNJRjZKSCVqTt7nN1A0A4Mxum0fDkAR UeBwlh5IgrKqk0AB2612yrYs7c1JFPAFVp360H7P34jZeYVbdBGOch3Va0PXlXt9+Rkb5Md0yjaI uef7SgKab/7LMc3TFU4qo+MfD4eIwWhzTIy8AvFRsoGPCkBCiKJd56ADtuzn/WydnoytxlhJ41Yr 7rQ08Axw0VCmZkiUsiNUtTi5r9Pw5LhtmBb/AP/WfIyiNB6YUt0YVrm9A3dYeaixepUHfuMl1VTY 0NepOx+WEIW8WJ5A0p1wlV6ULMZG2VaqAOp8MCjm0xTjUEhq/Z6jCFK08aU74hLVA3se2IQVpWgA puOpwpdU08COmBV8ZYCoHInrkSqoiRru/QdP8r54N0jmmcQovSgzQZvqdtDkqLlLNWVW22wKyfSB /oi4YsJG0wybB2KW8UOxVwxVvFXYq3il2KHYq7FXYq7FLeKHDFXYq7FXYq3ireKXYq7AhrCrsVbx V2KXYq7FWsUN4pabrirWKHYq1il2KuxQ6hxS49DirEdapzlJ6DLYcmiX1Jlcgjyzaim5jiFPoyWP 62WXaKQoWUnMxxCF3qsNjhIYlZfSkW05HT026/6pwwDAMT0cONPjYnbeoHzzbR5BxCjVSMglmqO1 N8mSWsK5AKDgpAoq+pXaprswyHVLYDUi3LEk1Unpg72QXkAuoLVcfawBSmtvKykNTlUcadd6eGY0 g1lVijaVjzY8e1N6ZGRrkoWzVjjPIBpu1K8QP+asY7n+ioCXMrMPVYlz0UnrmRfRtpdxLKGViwGz VHGntgtapfGYvhVKE15EHpUZE2jd/9enBLrxNe528M37qt7aAZnZhtXthTSzjyarb+HbFSWuRUkA VDbEY80tJE9SRsfD2wllwtOaEADeu/ywMWgV5Ny6jp74kFW3HEBu57YUS2WUJBOKS4daU+nFK9OK EM/2uvH2xY0vpyataqe2VSOzOKZRcqb5oMh3dpEUrqtKGuVFmFdTVfkMQlk+lrS0T5YYtckbk2Le KuxV2KXDFDeKt4q7FLsUOxS7FDeKupirsVdirsVb64paxVvFXVxQ7FXHFXYq7FLeKuxV2KuxV2Ku GKubrirWKtYoaxV2KVrniK4koXRlmWoUkDqRgVe5BSoHQUwhWG61Q/WD7H+mWAtctpJnqCsPL1oo O/GL/iOTw/UjNvFJI6dGFKd8ynHPJcVBNcldNMjuhdQNLK4NK/u3/wCItkoc0BjGjL/oKBjUMAUH getc2w5BwyEdwMjMoG3emTugxpUhUKwX9rqFr3Hc5CRSQqqykgqFUIwqabmpJ3yNKFzJ6khdV2rU b4AaCTyTO1aSRKP+6VejEdT/AJLZjzof0msqi3LRhlhoFPXbc/62RMb5oiVC4uTw9z1Py65OMGUR ug6u422WoP4cst5NpK7cjkq0XpSp6+O+BFt8vgow37UxpIf/0Hs7JvxopFFPsc3zq1MI4G9eNagY WQFhY3Isfc4sW5VKkIeqih/riCoWKrirA0psPpw2m2gGApUcjtU4UDk13LAbU2riqwEkE06dcKRy XJUnl2XcjAVK7qeQ6nocQrgtQSevfEpVUHIqBtXbKp/SWUOaahRSg2znp83aq0S7Hlv4ZAmkhVRR uBgtLKLAUtk+WSi1yROTYuLBaVNKmg+eKt4q7FWwMVbxV2KuxV2KuxS7FDYxV2KuxV2Kt0xV1MUu xVvFDsUtYobxS7FXYq7FXYq7FXYq7FXDFXHrirRxQ1irsVaxSpXLcYmY9AK4JclYvd+fH0+W+s1t A7Wy1Dl6VJoFqlPf+bDGNgKQwy9/NvzDBFyWO3ClitDFy6e4cZkRwhFJWn5ly3fMX1ugLjdoiaVP +Q38uSOKuSCAWe/448sarpltb2d6BcjgDbyqUf4F+LjyHE5CEZAsckbCwOTShqp3BzLDiKlG7Hbw xYEBCakaafdePpSUqab8WyyI3QQxvTOC2cBBJAQAGlKGmbaPJwjzR0SnnyJP+thJ2YKxUMC1OtGD jrx8MrZS5Kot15IEYOGHN+1B/lf6uDiUIhBbxUcsZWBoq14r/wAF9rKzZ/ooKYwj1JPjFNgQh7ZR LYNSy6ojABaHxyUN0xCAPrLC8hA4u23jQZdtdM2reNJOQDUbtXpXpjMkJJLXo8DQ0DDcpWvIeK0x 4rTataxK8tHUiIg7seIBof28jOVBSX//0bkBYnkSF/ZJzfAusbuPU5heRpQHfp0xibQFEh2cKprT thVcFdyQKs37RpuFH2sTshbKVr8NSvauEJDXE8an7Xhj1VY4IC+LYULxGqqaUYjdlr0wWkrRIQDT YdgMKBfVoMDsNsBZgqgpxI6sOjYChUi4tKlCBxIBr4nKMv0yZw5/1k1CkMx8c0MjbtgVSP7WQKVc GhxCLZPZClunyycWBROSYuxV2KuxVdirsVdirsVdirsVbxV2KuxVuuKt4q7FXYpdih2KXYq7FXYq 7FXYq7FXYq7FXYq7FDYwJaPXFWsKupirWKHYqhr6v1dwOpFMjLkkPKNdcrqGst3IVfvZQctgNgl5 9qDF4gPFi30UzNiGJSsCowsQLTHQyf0lB7HEbsj9J/qvUdL1FVYW8h8ArH9WXyhs68ysp7GeTe+U sSaQWsf8cy6bxic/8KcthzUlj2kjnbQgVJCitPf2za9HBTHkFlCijEGgHQEjxyNbMVdVmlLCWojX dpAAv6jTIGhyZhbLEyqsiikVNq9GB+WEHoqxRH6YPA1BBWpNK1wm7QU+gjrIDQKaAneuYcjs1Et3 qBo1bfauCB3UIKRV9YyKeSOKgGm23sFy0cqZBSAETFqLXrQZPmyXxqjoG4heI+J+goT2p45EmlKm 1zO8gRgViBAReihR3b+d8kIgBkQ//9J9CT0Lf5P9M3jq25Sxc1+zTY+FMMQgKLGpFDxPiO4yQCXJ 8MZ3ILV+IGlVOJ3K00x2FBXwA9sIU7LTy+1UV/l74hXMCp5dT1Knt9OKqe52Bop6YSlsqalQOmBj e7uA5AE8R3JxsMpbNsKD4Tt4fxxBUK+nwiW6hjXcs4GY+c+iTZj3kyW905rWMMTXxznxzdoEGgNR TAyRCVJoeuAoZTbCkKj2GWR5NZVskh2BW8KupireKuxV2KuxVvFXYq7FXYq3TFXUxVvFXYpdih2K XYq7FXYq7FXUxV2BXYq6mFXYFdhVvFXDArj1xVrCrROKuOKtYqhr7/edq5CfJQ8i1g1udZY9Ayj/ AIauXw5RSwjUEIh2zMgdmKUgUWuLKqCYaCC2pRfScIYy+k/1WbSfA9d612+jM2PJ1U9in+jasJV9 CXaVfsE98pyY+5IIKvrrn9GXR8ImFB7imMOapPphT6jDuFPEcfmM2QcMlEgV5zzNWRiQY+vIeP8A k4fIMV6u5+B1+EggDegqMFNnJfGlxxqpqpHVSAB7EYCQwBsqkLKQVJI2owGRkmSZWrLyJU9e2Y8w 1FM7qMGziK1qTv8A2HMeB9RWQqIKVSqxkLSVIpQkbdOmZI5bMo8lAxg8a9KV+jwyVsrbMiCX91/d qfhB+XfGtt0gKVGmNS4AqT36+H+s2T5JOz//0xPJN67gLQU7nN26pQDMxqG4HvXcZNPDbT1rwJFD uKDEIpTdCqgA/DkgyWSEdtvbEIXBTwDHqdx/XHqgrJByZe57++AMmuJqCtBTod8mhujs4X9o7fTi tOO5oOo2ORSVx2ohFQOn05FIaGqQ6Tcw3Dx+tRqiP7PT/K3zF1JuNBvw809bzimq+nai09EuOYfn ypTt9lc1EoU5o5qwQ1BH05V0bRzV4RVwPfIpkyiEUjX5ZZFpKpkkOxVsYq3irsVdirsVdireKuxV 2KW8VbxQ1ireKXYq7FXYq7FXYq7ArsKt4FdirsVdirWKG8UuxVtcVWnrhV2BXYVdihbiqGv/APed shPkkPIdVVnuNTVBzMkyKOO9Ty6CnXMiPRKQ6t5Z8wRWomksZ0hFeLtGR065fjmEMVMbICG2I6g7 U+/LiEgpl5ejrqkRFdq19sESuSI4SWazRjmyk1NTtmfHk6qRFqSqytVNmHfIgNZG6PvNRZ9JuIZd 5BEwQ+ORMQC2SGyG0yeCe0j9MVdFAPahpmdAuMYghHo7owJAYHYht6e+2SItqpUlkLMCihUIqOJr /tZGISVRZSsSgozqgICmvEM5+L7OAjdCrE6oQfTIoQSA3IEV3yBFpKNs5nNxTZlapotKgV6N/q5X OIpgRsn9xy+qwgn4aVFOxzCjzKct8MUplUFSWb4Sa+mPb+Y5kBjEoa4LunMLxjFVrHsagcqH/Y5Z GgypRgEfpxK4rHuzH9rbxyUrssmlHMEITwNWCgHbCdmT/9Rcxqo5Bh7eB/1c3luqtSdGqNiB4npk glwWhJBrt1Pj7YUWpFuX2hRq4Ql2ytyf8MVOy0g7EGvYHtipFtH7Y9hv88V6rgOKkdfniglYOPcm oNcLJs8Kkr0wK4dAepB/DIlUl11iZYqfd88wcx3LlYe9MtGWt7H4LGT+I/rmBM7OZBlamrEVpmK2 9VeAfvAPcYoLKY/sD5ZYGpfhQ3TFXYq3irsVdirsVbxV2Kt0xV3fFW8VdgVrClvArsKuxV2KuxV2 Kt4q7ArsVdhV2KuwK7FXYq7FW1xVaepxV2FXYq1ihrFWmUMKEVGKUC2jac0gk+roHBVgQoB5Iao3 +suCk2jZGb0GUk0IIIw0xYBrHl/SbkmOW3Q8nVfsiu5+I8/tZdCRAawd0Lrv5eaNossV9pSyrVm9 WN5C6qNqcK75biyE805JbJLccC7FT1ObOMgQ68xoqQ+0B45JSN2mNTVhUd8hLmkbofTo0j1GVE+G N1BcfPwzKxuKedJ0OALKn2a7eNMtYLiHYhiACzBQFFAK/ZxtiVTdEKOxHE0IU1rkeaqqQguqAkBj se9O9ciSko21HpyAAglvskChpXKZmw1y3CfTNI9tHX+UGgIzDiACmZNBLZowFqDuakjwAHXMiJYB Al+IJHR6e1SPs5bTfTSPIpfgnIH7RHYdMZBadGB9kBg1KAV7HviVJf/VErJISRQlurKR+rN4QHVS AWSGQfuqgAnkx7/LEL0U5WQ7KaUICj3yQQFir8RVj7lskyWB+R4j4VHc9cVDVSSabqeh6VH+rirR qKgDbxxHNLTs1KZJacpY7DfAVco+IlumBYrlckmvTtgPJUj1kg3Kgb77UzX5eZczANk30QE3pp0E e+a/JyckMpCggGm/jmO3lEWo/eoO9RgLFk6fZHyy0cmpdhQ3irsUt4q7FDsVdirYxS7FDsVbxV2K t4pdirsVdipdireBXYq7FXYq7FXYq4YVdirsCuxV2Kuwq2MCrThV2KuxV2KGsVaxS7FVkv8Adn5H FDE78EzKOtZY6fflwqmofUnPmHYQHuGNPpw4eZYZujENU0MTI01sPiG/pgZmY8lNPNjgj4sQ1Qy9 fbMyJ4t2siljMPs4kMYnZD2YH6TkNdgi7fRmTjcfJz2TqIhW5BfUqKmnUE7fhlharVoatVQvwqC1 fY98jLZIFuQhWVFA5KTVj136Mf8AVxKapEK7UDM/GQ/t+xFD8OQIQUXZtT92rl43oCoNPsnkvJf5 VbKpsSU6cD003oAo6fqzEHNhJAXTF0IT5FT4DqOWXQ2UDdBOsjsB6Xxfs9wF+eXAgdW23IzQI0ZA eu7ht/h8FxI4t15uT1YxyUBOWyMTXjXx/l5Ymigv/9YSlRL6hNB4d83hDqmpxViT8PL4gO/4YYqE MqqwKqaknJpczKQa1+Hb3xVT41Pw/jio2XLQfwxTa124nx/ViqxuTGuG1bRyoIpue5xVuoY8Rtt3 wIXRrUV8DgKUj1CGWS+EcSF3FPhUEnr7ZrsxolzsSfaJbTJeSLKhjYIPhcEE79q5r57hycYssiQE EDt3zGLIou0Wt0tOm2BBZIOgzIa28VbGKt4q7FXYpdih2Kt4q7FLYxQ3irsUuxV2KuxV2Kt4Fdir sVdirsVdirsVdhV2KuwK7CrsCl2FVwwKt74q1irsKuxV2KGjil1MCqc392304VYrdgm5hINP30R/ 4dRlg5NBHqTTzEo5RN0O4PyqMswdWOfolaEKAUJr79MuaAlWsaRHMPXtlpMP7xF7++W48pCmixaa Mq5B2IzMjK2mUaUtNAOpTFh8IVAT8xmTAFpKd09FlkRhQmtR2ByfPZoIVY1EsqoKsJWAQEhRsfHf 9nIHYf1WfE51HqStGC6cip50qtG23XbDE7C0rlT1Sag8l3qBVaV49R/lHBdMSj7OJq8iAAPDqCOo OUzLAlNLe5YBwQCOHActz1+KmY0oseKkJNxPEBefE1ZCSAQOnKmWBIPVDTyl1C7U5EsRsN/2Nssi KbAOqiiKxqPhT9ok7fIZMlBtUdHguAY2NYyOJHUkHt/zdkQbG6jk/wD/1xvJBUmlVG9Dm6dTSHkJ ajKta7HJBQpg8CabU/DJ82XRbQSArWh7HxxqlWmo2Xr0OEK5V+OjdO+KA06qzGhp4fLFPVoMEUg/ b/ViloHcH7VcKW1o25G/YYGK5AS/H7I61OAptMvKc6W+q3txOKIkQCk9yW7ZqNXs52Epxd3pv5RI FKKoooOYLlwOyxVpucpBUouyA+sqflkqQeTIB0y5rbxVvFW8VdirsUt4odirsVdirYwK7CreKXYF dhV2KuxVvArsVdirsVDsVdirsVbxVrFXYq2BirdMVapirYxVb3wq1irsVdirsVdihquKqc3903yO KWMTitzCD09aL/iYyY5NfVMfMNGeJT3Vj9O2W4WnP0ShKpWvQ5fzaA7kQxK7Vw0stgkHma3t7a1a /oaIVWRF6kueA4/fkoSPRPEJbJNZ2jwXc8klAp4caGoJoCv/ABLNri5OFLYlMnROMZLcSwPNf5ad P+CywE7tFLgvIBUP2vtL7DBbMqqxvQiMExggMB1p+11yNotWSMl+EbFYSaBCaFl6/Hw+H/Y5Env+ pkeSZQIokcmvHqa9zlEjs023uzfBsw3I8Bg6KQ1czKYmqwoftUFDUYxjuoCBQoGHOpUip4bn7suP k2xXrR7j7JMQBptt/wBd4OQ80G21QlqcixNDUmvwjfASt0//0BTuFhKD9omlfA5vK3dUoyMyvRQa ECmGIUNLWnxjcGvE7VwpUyCWNBQHtkglYQooRgAUnZV+ILVTTtgAY8gpN8O5NTkkgqRU1+eKSFZB txJAPviWS4fYKhtuuBiQvUK7rX7I64CjojrMBS47dB9PTNXrj9Ll6UbSTJAQM1lOcvXrgISEbYb3 CD54hSnw6Zc1NjFXYq3irsVbGKuxV2KtjFXYq3irWKW8VdirsVbxV2KuwK7FXYq7FXYq7CrsVbpX ArYxVrFW8VdirVcVbBxVbirsVaOFXYq7FXYq7FVGf+5P04oYzMC93bce00dfodckOTXW6Y6//eRD vx/rl2DqwzBKu2XuMsGzVyRYhJPNjr+iJCftepH/AMSy3FH1btZ2CX2oVIhWh5Dcncj34/zZtKca RVwI0hL8pAxNBXun7Tb4dyWPRcZGcKoP7wgqjAALTqOmNUoK/k9CS3EsBRfoyNMlW0jLXEaxsSK1 PbpkZnbdB5JvDQha0C78qfM5iyai2tAzemN6VAHh4nAfNKhchRB8R3Y5OPNI5qESOGK8gAUJ3NQe Iqo9snItlhaaBQDuW6v4YUE9zcQcsCQWVTQqB1rgktv/0RLKamnVvHsvj/wWb23UqbtGIkVK+ruC x6de2ICWpWkJCE8nAFW9sISFJz8O+3vhCFrLuB1U4bZKjVYLToBgYlRZOR5dhthZNEcffEKSqDpy PfFILaior0Ynp2xQSv3XIST0R+nnkrk/zLmr13OLmaUf7JM16HNdbl0uRQWyJKeSYaeB9YX2BwA7 sSU6HTLwwbHTFW8VdirsVbxV2KuGKrsVaxV2KW8VdirsVbxVwxV1MCuxV2Kuwq7ArsVdhVvFXUwK 3irXXFW8Va74q7rirfjiq3CrsCuwq1irsVdirWKqVx/dH5YoLG4/+OhaL2aYV+gg5Lo0QO6O17/e mP2T9ZOXYeVsc5SrL3HWmpc7bYWJKQ+bRTSSCaFpIyD/ALLMnDuWGUUEEIuEaPX4vHNmD0caYV29 eUIzkMoHBAd6DrQYNggBaI+LhOjVqG9sPFamKJEQCPX4nUDiR4dMr4t07oi2hZZIox9thUmv2aAl h/rcchKWxLEo9VAA4k8WXevavSmUEtdr446k8QCSKH3pvgJW1txJIiceBoBWmx3P8tcMQClB+i5Y ichZKclYdKD9nLOLuZXts2V4Cu7DG7SqlF+B0HGp3c1+1+z9kfZyNof/0lgzEt4dAfbN86pZGBXi d1HQYlN7LiQsgqaUO9KfxwXsjoskIZqUH8f+acQFWGpb4eh7jJBk3yr9jcAUIxYnmt2KGjb1+wBt 9+FktRCwPI/EOgwWgrwAOor7YpIteFYgtQgE/DgtC5jRQCKmvU9fuyKphpyhUY9a9Bmq1x3dlpuS YJ0zAcmPNVjG3vkCxR+nD9+PYGvzwxQU4y5g3ireKuxV2Kt4q2MUuxQ3iloYq3irsVdireKuxV2K uwK7FXYq3hV2KupgVvbFXbYq7FXYq1ipdirsVbxV3Y4qtwq7FXYq1irsVdirRxVSuP7k4oY1F/x1 bHwM39Tlh5NMOaP1wVuE8OGTwsM6Vb9B9+XtAcR8PWhyQYTY95v+LS070ljUH6a5l4fqYTOyyCKO TgjuEVz1IJCqR9r6MziSHHmejfDiyKlZBXf9nfp8ONo5O4ryJYkybCh6AdsKr1kkUj4aV+z4ZEgL aMsgyyAyE8zyZivWp2+LKsnLZgSjYxWJkChT15HqKfZ2yo82C6JWWMtTc7V7E07UwE7slOQLKgUk rSnxd+Q7DCNkKSICOPChX7TctskSyVYRGT8ILJ2TqfvyMrQWzE7AhTT4hx8SPDESW3//01KcV68v YZvSd3VAt7KuzBidyFrUexqBiUBSP2vlvhAZ2teoetDUdBhQ2hauINoO7VQAf5674QlagofnhKrt ww47+JyC22NzXuMbW1YRgoHZuBPY9/lTI2jq1zI2AqO2SpNJlYqfTBJ3qc0ut+p2Ol5I5dzmGXJp XiBFcgVR+nL++Y+OSixKbjLWDeKuxVumKuxV2KtjFLeKGsUt4q7FXYq7FW8VdirsVdgV2Kt0xV1M VbpirsVaOKtYVbwK7FWzvipapireKuxVsdDiqzCrsVdirsVaxV2KuOKqN1/cnFDHYIyNVsOXQykg /JWywmw0w5ovW/8AelR4J+s5PEwzpZwY+2XtAcUPTr75INcubHvNqk6fAqivK4QAfR/ZmXg3kxyq QhkjCCvL4dwOwpXM/iBcaZ3V7ZHUcvhAkIapPgNvlkZEIcvABVZfi2HIb0WvHEsui/0A1WNaoxTb xH8rZHiYWjbS3BkYqSVQAGQCgNRU1qftLlU5bMZJhFE0QBNB6o6nwyiRtDZ+FmTqB8NR4V8f2sCl Czq4ZQBQNQfR0yyJVQIUUVwzR719iuTZxVIAxlDIR0KqOmzfDU5GXJEnFVDKjElohxND1H0YQr// 1FuVBUbN27ZvHUlYS1eRFWOwrhLKnAF2LqOFBUg/8a4VcJWrVRVu5wkWimubg8iBvgpWy4D1pXxG J5JU3JarAUrsBhioaBZSAu58MSlWDVFW69OIyDDq5djV9h0oO+LIro05DbxwkokaCbWSUjAPic0e sPrLs9NtAIhahqjMYuSiVrtkWJTDTPtPhixKaDLWLeKuxVvFXYq7FWxilvFDsUuxV2KuxQ3il2Ku wK3irWFXYquGBXYq7FXYq7FXYqtwq2BgVvFXYq3gV2FXdjiq04q1hV2KuxV2BWsVdhVQu/7k4oKQ WdBq9p/rP7/s5OtmiH1IjWiBeLt+yP65bi5MM53QNT17HplzS1yZTTjX3wtZ5pB5oKiC0oOlxGfw bMzT82ORzFECyAVP2j32Pw0zLG+zjHmuRgrqroOB32G24/argI2QeSnyJNeFQVAB6UA/42yVMui5 GahXkSp3IU71/mOJDBHWXE7qPVBHxVJAFP8AJGUZP9KpR1KUHVT1B7ZS1WqBAI2owIrsO9TvXI3u qjMr8hwryXiaduvxE5OJSFA8TKepYgjrRaMak/fkujJevKPjWgEopTY7A7fjgO6GmURu3NuwHLwp 0xu0h//VEFVcGnxeDds3nV1VqbqFiAJHKtTkhzSOazkopUmn4YUnZeAvL06gk/tdsCLaFKMgow7P 3GEMacwMjMeI+ECtO9O+PJK1KKsiUDE03/lp/XFFb2vCqQpPUnf5ZFla0qgYGpBBrQd8NpK9E9Qk dwCx9gN8bYjZVVWVOf7JGRKDvsmltT0VA775oNR9Zdth+gIqP7QyhtVh4YEJjpg3bJwWSZDLGDeK uxVvFXYq3TFW8UuxV2KHYqHYEt4q7FXYVdgV2FW8CtjFXYq7FXYq7FXUGKuxV2KuxV2KuxVvFXYq 7tirRGKtUxVrFXYVdgV2FWjiqhd/3WNKklltq1uD0PMj6FOXE+lqjzVdZ/3rPb4QPwOTxcmrOgV2 XLWjo0SCa4WuXNjvmg8EsaUoLhSK9OhO+Zum5tU+S8gMoclfUc7Ku30hf5cyhs0clUMlDGVq4HQG vxDpvkaPNi2VjRAo+J67r2AP2sbJSvdIzyKioK8VU7jxanH/AFciCVX6cQkq+k1BQlhTcnpTBl3G 6kpnUfE5HIt02/hmPTU4tWMRpsCasCO42FMetpGwpSmDUbk3EcfjZfAfst/k4YpCgqu7ow4ycfhA cbAD7v8AW5ZM0AyteeCbjdPsiiigJ/1d8ixXC2mlDcIzJQmrDoB7t9lf9lg4wGQgTyf/1hPIKeKj Y9h0ze06kqEoUEVNa5IMw0QhIUb77/LFSbaCNQMOnTieuKLXCoUsBT2xBVTrUk9j4YVVk4sSa/EQ ensMiStLF6sCaVA64UKoRCKhht18foyKSVyoz1KEHj1qQKUwEsbVYI1lkX1HAX9pvbBI0t0mwRE2 jPJex9s0ObeRdrg+leOuUNysq7jc4FTXTfsnJQYlMBlrFvFW8VaxVvFW64q3il2KuxV2KuwK3hV2 KuxV2BWwMVdTFW8VapireKuxV2KuxV2KuxV2KuxVvFXYq7FXdjiq0Yq3irRxV2FWsVdTArW+FUPe /wBycVSSwB/TFuD2EhH/AAJH8ctlyaYHdW1YK12xPUAU/wA/9llmLkwyi0HTYjLGjosUL3yTSx3z OwaTT0NCrXG1fALTfM3Td65d1bjCGp9ta/DTbb/mnMmy4fNsJGxcgUNPgHiB1wWUKkKSLHzcUQeP vkZEXsyK52ki4qD8J+Ir/Mo3UN/ssAAKERYO6uzbr6g+MeJrXIZAwKORjuSAQT+OUli4Rgj7VG8A PHG0rbiNWqgqSRRh44YlbW/VooBGZpDXjX0gAW602ph4ieQbKCqZLe3o6w1n4grzO4Dd/h/drkKJ 6+lPEByQE91dTt6TSERJ+ypov3fZy6MIjdeI1T//1xUqiJ3jVwdjU0rU5vBuLdQd1BuI4EqR8NGq agmv7OSDJuNKsTGtaD4i3b/VwErbmdefv0rh6LS1mLMQd19sPRK1aH5YlLkUfFXoBsOmLGQ2VAIy nw8g2/NT9mm3CmDdEXKoBP44sl6U517VwMeitFxJ4stanYZGShNogBGtOlNs0GU+ou3xRqKIRRTb fKWxUUEEVwITTTh+7J98sggo7JsW6Yq7FW8UuxQ2MVbxS7FXYq3irhgV2Kuwq7FW8CHDFLsVbGKu qMVbxVrFXYodil2KuxV2Kt4FdirsVdirj0xVoDCrsVaIxV2KtYVdgV3bCqFvf7nFUo088tXhr2jk p/wuWS5MI9V2p0N7LTtSv/C5bj5OPl5ob4QDvk2vkFPJloDHPNJH1rTaj4TKdu3TvmZpUZCriJkd 0Zgvfj+yP8mvXMm7DikqkdQgBAU/5PSn04CwPNUClAOTcjuXHYjt92Ru1JVHDNEZCR23pkRzpQiL VOLGp5lu3WgPf/JyEyhFqFCtTtsQN98qQW0Vz8IHJ96gdN/DEqAVl0WhQlApmIFN9gB/xthhv7kk ISsiAtu0pFeXhXqzH+bLNihRPON+deYboB9oD/KY/C2S2KQ0oBerkKpNGIOw8K4Syf/QXuTxehPG TwPXN7Dk6kLPTZlQM2xNK4bUlseogYr2BA+R6/fgpKyQ13YbAdB45IJWkqu4rQ9seajdfxVUq42Y fD/XIkoJ3bVxSgFdqVOSpRzcUHEe/XAoVEb93xZdx3wILa8V3IqK0YYlKun2latU6BfbKzyLFNY/ sqvYAAZoMn1F3GP6QrqKClcrbF69RgQm2nj919OWQQUYMmxXVxV2KuxV2Kt4q3il2KuxVvFXYq7F W8Cuwq4YEN4pdirsVbxV2KuxVqmKt4q1ihvFXYpdirsVdgV2Ktnpiq3CrsVdiriMVaxVrCrsVQl/ /cn2GKClOmf8daPb/dch+/hlkuTViPNvUCPr03uR+r+zLYDZqycyhyoI2O/hkwWo7rCCNj1yd201 THPMrf6Zpu1aSuaeNVzM0wa5FXiJLEOKuxoPY+OZJcYqtGHwkAkbE9q5FFKqxSRghmFXHwsT0+jI EgoK8klC1agDY7bjp8K/PAoNoq2YcG2qWUVrlcmJO6JTlxCsaMdhtQ0yspXNMIf7oBKihZevSnX3 xEb5suOuSDlKACoq1f3dT3/yjlgY2gyCHYlQI2pU1NSQaf8AEstZc2wjhCVoeRpud6YL3VstGIqA MG5AFSQB9KnGjaX/0VZByNTWnEffm/dUrCjvxU0QUFPAsPtZA8mPJRc1c0qQppU+AyQ5Mg5yyuGA +IEYq5FDMyyPxapYbcgfBdv5sSq0uxPGhPanhjStqwU0O9OuJVew+FaeOBDZJLlR0PfHooVERSad B1J70GAoKu0SVJjJpsVJ/hlZOyIncJjHUIvjTNDk+ou8jyCupNN+uVpVV/HApTew/uRlkGCKGTQ2 MVbxV2KrsVdirsUuxV2Kt4q7FXYq2MCt4q4Yq7FXYq7FW8VdirsCuxV2FXYq7FXYq7FXYFbxV2Ku PTFWsKtYq7FXHFVuFXdsCuwqhL/+6+eLEpXpNf0oPARN8+q5ZLkxx1ut1AA30pHZuv0ZdD6XHycy haVauWdGpeFB69cWBY35iUnUtLVRUlnNPcBKZnablJqy0CEcsMtDyUqxANKb1p1yziDiGQC5I2Kq AArdweppgJY2ukUl/SJ3WhB96YAdrSrQwTJSZmRQhqHegHypQlshKQOyhG231FUYs7MaEDitBWtT u3xf8JlUuJkBDqqiT4aQUVnFGXvx/wBlXI13pB22ajt6VL0NKV+MAD5nEyTHHv8A8eQV5E5qimP3 CuDT2y6BYSjRURbSyEK4VBvxlY1UEbrXj8W/2clxgJhzVYrYxgMZUSlCSzAdfBN3bjkTK+ieG2uN ozfG7S1NQI179qtJx+H/AGONySAH/9IYfTdqp4HY5uwSHUNfGkewoXO7HtjzVRZVU8i1SGI4j2Fe WStMVrI7/GTQ98ILJ26dDXlvXChcsnKoXbepPc4EU3wG7GgFcFrbce4NenamEoVAvx8QKUHXIqvi BapUVYHp7YCpRAEh6Gig7fLKpckRO6PX7IzRzO5d4OSstSdxv45WnnurJ1wLSb2X9yuWQ5MCihk0 OxVvFXYq3XFW8Vdil2Kt4q7FDsUt0wK3irsVLsVbxV2KHYpdirsVdgUt4q7FWsVdirsVbxV2Ktd8 VbxVx6Yq13wqHYq1irsVapirWFXYqg9RP7ojCAxkl2k0/Sjf8Yf4jJS5NOPmVK9cC9kBFfiNafPL 4j0tc+ZUOQ5bDY5NrLZYDp1wtZ5sc8wNTVdOq1CqyEEeNI6Zn6X6T/SaJ7yRqMzASySH4lXv3pky OgcSY3V1l4xDjKeYqAzBWUjtx+Hmrf62QMd+StxX9wgZ0cc6UDAKG9jXjicYbIkjcNieSjLKwZgC TyAYkn5cMHCOjXzKJtk+EM68VJILio4kfsdeLZXIppfPK5UqnGJCN1XvT+YnBEIlI9PSoV+FVDAH 9o5NiEPPQku52A6gUBpk4sgh/iJ5NuQQONCftd8m2W2yMCeQPGtA/GlfbliCt9VwV0o6Gp8Dgu9l t//TGhEMRavH+Ht9Obo83UXupVl4hSfhPbClsoXpxpQd/A0pio2WcxXj1HT5ZMBVjhdlU1C/xwpV ePI0WgXxyKHFG+yfo8D74VC7hxI7UwWgclTkGk68QeoPb/KwICqjGN6r8siRbExtEJVqBfGpymfJ lAepHKikA5opbl3tqq9chajZUXriSqcWn9wvyy6HJgUQMkhvFXYq7FXYquxV2KuxS3irsVdirdcC t4q7FW8CHYUuxV2KuwK3irsUOxS7FWsVbxQ1il2Kt4q7FXYq2fsjFVuFXYq44q1irWKuIxVo4VtB aj/dnJBiUBo1TqUpPaEAfScMmnFzKHvQPrUpH2uTfdXMiHINU+ZUR0yTErcmA1Fj2s8zrmm8acqS den7K/wzM0+0S480d6YHALtInWooKEdcstxiVRYetTUN0ZBy/XvgMkW6SIUbkBVhsDsdvDESZAom OyJi9SVgkW4q3wlj9qif8bvlZnvsojtaoCz7FQiJuiL08Of+yyPJiTbYCKqhdvb54GJcY6V4n4iD sQK/9c4bWkNcIhYLyFKbr3ycSWS2saMCrMyuP3q/ZKlfh/a/Z4/tY7lkVg4sqoGIjWp3JIYnv14Z Lkm1VAqnfp7bn7sid2Nv/9QYpeGPjsAd6/LN4RbqebpSWjD+mfSPV+3LwwBEVBnKjiq0P8/ev8v+ rk+bK1yPF6a8hxdSat1rXI0bRRtoBySK/D2pkilW9GiyCtGouRtja0CiVpsBvhTa0GvQ0OFKuiAc QRtSoPjXIEsCUQvEVJ39srLBEIhZ1KrSopTtlGY+gtuH6x/WRiigoc0xd0vBGRSqJ16fI4qU5tgR CoPWgy2PJgrjJIbxV2KuxVvFW8CXYVbxVvArsKupgVvFXUxQ3il2KHYpdgQ7CreBXYq7FXYq1irs VbxS7FXYq7FXYq6uKtnpilrFDWFWsUuOKHYq0cVaOFUFqJ/dmmSDEoPR+J1G4p19JK/S2GTXi6oW 7HK5lr2c0+/L4cg0T5lROWNUy0RTfFqIY9rIH6e0/kvIBHJWtP2xmdpvoLXl5pokiKx/dCvRVJ5d cJHm4ZXhyCeBCsagFdumClcXZGjZmDylfsfa6ePINjVsgFKRzI5kkLM1KUrU9f2eX2RkgKFBZK0I LL0YKTUId+NMgWKL4ggVABIqGPbK7XhWuqgh1+Ht9HhiCpQ8yCQ8mIX0xUeJ7HJxNKpsrAgKN3A3 PQgdfwyVsgtSIAohHw0ND+yD44TJkS2FBYV5MqE8iu3LBaH/1RnoO8nBQXJ6KM3gltbqbczshEY3 FBsTUCvWoHfI0xG7RQMzCgoAeXt4dcINJWIoZQAu6KR/rU8ckSkldHGSQIR8RFSPDAT3oJ71SN15 nmaMQOTHptgIQQqrHCQzeqtDsF6f8N0yJJQSVotiBy7D3B64eJeJWpSP4hxIAC1HXI9WLaxO9Qg5 ePbEmko6McRGqMpK9VrU/dmJm+ktmD6x71YU+Wah3ZVAAFwIVFFSvzxVOYP7tfll0eTEquFDsVbx V2KuxVdil2Kt4FdireFXVwK3irsVdireKHYpdgVvFDsVdirsVdirsVcMVdirsVdil2KuxVwxVtum IVbXCrsVaxVxxV2KuOKtEYqgNS2jycWMkJoq/wC5C5P/ABXGPxOGfJhjFWhbk/6RJ7sf15kR5NE+ ZU2U9sk0kWtbpQ5IBhNj2pAt5hsl6/uZB/w2ZuH6CWjId0zhj5EV/vtmQeHblhkf9K4pVj8CsTXn y+EeIyHNChSZkLOAvI1Pj9+T2S4FfTZwayDbbwx6qr2/Rfi2OQkpO6L+DZQOPYO2+Vpta3Snh18M QxUH9hv3HUkf5OTCqfp0YKWq3Xqdq9slbJayckAU/u1G1e+INKuhDKzKi8gKniviBUdcZK//1jNE JWhaknUHvtm4t0xO6iT2PQbA+OSSRs5+DMCxJoBUfLEbLG20NVqBxU7CnbCp5rTMQoVR02DDDSSN 1RIeXFK/a3Y/LtgJQSrx2qcqM3wqQ1CARuP+CysyYmS1IVoONOvUZK1tVRZmqOZKjtX9WRJCNlVY nYVDEjuCciSglEwqqKQKKabCmYuoPpLfpuaqB7U9q1zVu4HJepFMiyVkAJWnjijqnMWyAZcOTEr8 KG8VdireKt4q7FLsVbxV2KtjAre2KuxV2KuGKlvFXYFbxV2KHYpdirsVdirsUOxV2KXYodirsUux V2Ktt0GKrcUuwoaxS7FXYodirWKpfqX2QPfJhhNQ0Wn1q5Pfio/E4z5IhyKBuDWV/Hkf15lR5OJO e5DTMFPzGEMZFTpU9cmGo7sfvwzeZbcKacLdjX2LdvnmZh/uy0ZdinEfFhz34VpUe3UZEuK1VD8e wQbEdx/wXw4d1U2ZSeJ3jpWo6096YUtekCAlNh2w2oRUK7BlFPAfLK5IKo6NT4tvDbauRBRS8UHj Tx9/bAkKcqqJEYHjUUehrQ1pzHH/ACckDsyobKCxlqryrxqFoNjv9B/4LJEpPPZzpuqEE7UAHh7Y AUNVKElDRiNxTan+th5q/wD/1zGX1FUAijjqRuM3IDpwpPw4KW6jYqOpyYZL4hVq8RQ1K1O+wr0w SQuZHSiOQCd6DACxB3aWKjmu6Kak+O2HiUlWSiH4TU02OQO7Ei1eNiW+MUrsffIkMSF8bgqyUHFT 8Owr9+AjdS5E35DatdsBKoiLdfi6jwyEkL0HxGo+WUZz6XL0g9SoPtZrAHbr1AGBkqps6e5wWxTi P7Iy4cmK/ChvFXYq2MUt4odilvFXYodilvAruuKt4q3irh1xV2Kt4FdirsVdirsVdih2KXYodil2 KuxV2KupirsVbpirbdBiqzCrsCuxS7Cho4q7FWjiqA1IVA+eTiwlyQ+hj9/dnwKj9eGfRjDkUFKh 9R2r4/rzIDiSj6iVritCckGMlnHJcmCRyCvmqPblxtTQf7LpmXj/ALtxs25TaVhxSBAFMahSoHfA O9okbULhjIFjI+GP7DfZ9+g+1k47bottaoGkUgMBtXoSTxxO6FyE0C8iqSfCW60HUnIlIKJgZWj5 e9ASTU0yEuaeiuU67ggbEd8haSFoVVUdK+Fa4ebGqCHmYkkAdKUb3rk4hC1viccvharEsOmKhfyZ UDBQjCqgkk7n7LcWwUyu1NRv9mjd+xwlD//QMAzOSF2FaUzdOoadADQCpX9vvhBQCvWINx+Fq/aq QN69eNMiSxlIhV4EnqCR9J+nBbC1UO4XjQUPyyNBJDagHoo4ADf3xtHVWCCSg7rvkLpFtqq0YAbg 1DDsMSgq3FDESBSQNxC8WG3Vm5fZ/wBjkOrOhVrY0IU+JO4PVfDphJQvVaGuY+oOzlaT6lVRvmsL uFwBrv0yIKAVeL7afPCpTdPsjLwwXYq3irYxVvFLhirsVbwK7CrsVbAwK3irt8VbxV2KuwK3irWK uBxVvFXYq7FXYq7FDsUuxV2KuxQ2MVdQYpbwK5sKrcVdirWFXYq7FWsVaOKUv1E7D55IMJKWi7SX lPFf1HDIcmMeqCYMWYg9zmQHFl1U2bahyQaiVpFB75LmwKTAcPNJI/5ZR95fMuP93/nOPkTJCgRj IaMdq9zifJxbUypChgAey18D3yQSuKuoU1B7sAaHbcZG1WszAqSpJatAewOGlRdrGjLu1Cdh3/EZ XIs4xBVHRhQkddwdjWnw0wArKJW8DQlSTQ7jwGNsQNlkyVI4sK+Ar+NRkgU0s9I9O4NNvl/zVjbG m/hq7yLVwv2iaCvbs2PuZxHe5hIBuf8AVPjtgFIk/wD/0TWjrGWOzuTUnqKHeubjq6YLYYyz7sV4 Vep7lRsMJKSV8S8W5MpcU2o1B9ORkxtXABBIJXieKKB/HAxJbBoN1qV3DeGKFRATUtxHL9qlBXtt kSkKkdOK1pzbqKU6ZEsF5+BgSfhPTBzSuLCtPH9eClVIiPXCsoKivInof5aU/lyJ5M4893VcgK3b f76f0zG1FU52j5tgZr3ZrwN8AYlXiFZEPgckFu03XoMuDBcMVdireKuxS2MUN4pdirsVbwK3irsV bxV2KuxVvArsVdirsVdil2KHYq7FXYq3TbFWgMVbpirZxQ1TFXd8Ut4Fc2EKtxVxxV2KtYq7CrVM VaIxVL9RrtTrXJhjLko6IQTeU61Ff+BOM+jGPVCsNzXpl4caQ5qYG5p0ybQtKcjXCDSKSH4f8TTd 2FsnH6TmdH+7cbNyTf0lVgrg+q1ajrTbbIW4xitEMhQHiadCzVIHjh4gpVJQCAmwAoK96dqZEKtj QCSoB22BB3wk7KiYFJNSAF8OmQLKIsr5l+FApNV6Keg8TkQykNg0tFPcVHh3xKBspsak8VrUVIPs a5JAK1mRqFQQf2qE7j/K/wBlhCSQ0aFiAOVPh61BPc4oLiqemlSS4JDdRxrT9r7ON7plVP8A/9I0 lWSSXm4LOSTU+++bgbB0vFSKh5RLUEHr8J6bimQO6CVkYHPixJjFOXHqckeS2qPIoZ+NKA9+vt+G ABHCvAdlCVoH25Deo65EoK8GWqGnFAacvcd8BpQdrRDsJXUy/wB4K8mVRuSPh2XKwKGyTLi5rBGz qeVCFNFHetOuG2NLKH4Qp6ZJCJUgKDTc9MqZtinw03qCSfcHMXUcnYaQF2YRdivB2rgpVe3p6i+N cIQU2HTLmC7FXDFW8VbxS7FDYwJdhVsYFbxVvFXYq7FXYq7AreKuxV3bFDsVdirsUuGKt0xV1MVb OwxVrFDsUhvArsUNd8KW8Vc3bAFaphVo4q7FXYq1hV2KtYql2oGh+WTDCalon2b1vGSg+QXE7rEb IRupzIDjSWcRkmg83AUFMVY+OH+JbsMNvq8S7Cv7RzOh/dhxc43TqMxlgRyaOvx9mp02Y5AguMKa YitB0pQ4FkO5dwBDVO9RxI8RQfFjah1A4PxnYVUAdh9rk22DkkAEKiqSPiJbcUp4nEqEQ3F+HGg2 oa9vGuQ5N2xIWDgSKk8t+oxLDZSYEVH07dflkmCmASqkbsDVR4DockrRXgw/YYCi+5/aGN2pXVBc Eg8hQ7bDAt2//9M6t1mYh3NE8c28qdJKlf4BzqoIG6AdfpyvdisiSibfRkid1Jd6VZmNAAT8PgcP FskHZERg8+QO6ioI6VyuTEc10RL0B2psAehPjjLZVT4gWFTx25AGlSMikLiCzfACKCoBNNsC1ZWq VCA1qe22FFttxIp+0dz4VwJlyXIONB2p+OYeqO4dlpFwB5e2YRc9fQ+GBKJtV/eqTkgghNRlrBvF XYquxS7FW8VdirYwK3ih2KXDFW8VdirsVdgVvFXYq7FXYodirsUt4q3irsCuxVrFXYq7CreBXYq4 Yq5sVaOFWsVdirsVawq7FWqYqlmo/aHzyYacvJT0Pe2vG8Zn/VhlzDKPJCmm5Jy8OGebth179MKS 7gAOuFrAY6icvM14eNVWCGq++5zPj/dhxMqdqsfxjhwLH4QASePYZUbaGyoaqjdqihI3oMC+Sxk5 jkm7A9fl4jCDSKXQKW28RSvvgkygCjYgkbhI+lDu225ys7uRGgaDc7NX4KFaDkab74gLkkb2aMUz L8I3JoTUDt+GNhBhIhTliPIVA5V3IpTfbCCwlErFUh1oh5KDuN6ncf8AA4SViN25IX5sBQKKV3Fd /avLADsxnA2pGg2rQL0XvkmD/9SQIbYR0MlSBX4dz92bQ3boy3C4kBMaUKip5+GAikENndzXwqKe OFjalF8TlpDQCu3cZKXk2UiQOI4gGjNTfY/PIMVb0lVeTMD4EZC7Wm/UoKIta4KW3DmQ/P4VUVp9 HY4qFq/Gq1NNsPJjW6otGQ/zdqb9dhXB1ZjddSgAPUdcwdS7PR7xXA1zDc1erVxUIq1H7wZKK3sm Qy1guxV2Kt4pdgVumKuxQ3TFLeKuxV2Kt4q7FDsVbwK7FLsVdirYGKHUxS1XFWxireBWsVbxV2Ku pih2KXYq7FXDFXMMVawq7FWjirsVdhVrFWjiqWaj9odt8mDTTkU9AFLC4J6mZz+Axkd2URsoEBq9 svcchx4lQfoyQYEgraACpO2SYpHaRV8w6mw+JfTgFepqVJGZd/uw4ebnSctG6CspFCN+Rr0+zSh+ HKge5rMSOakpiRj6zMR0IHiRk9zyYRAvdUin5ciBycDYsKA9ug+WRIplGXNpp5yRzcFQdlIFPo6Y eEIOSRRUU5PEFUFfY0ysxbo5L6RVpHZuwUtQkgUoMAbJElaTLM4JcHgBu+4+HtTHYL6pHn9KCkjc Pua918KA1ywFxZAguDOPiFeJ32wFAJbNVHMsRyJrQb0p44sjtupcTQEd/tU3Ph0yTWQ//9U6QUO6 F2G1V2zbF0aICh/hQGtPijB3P05C+9DYT4TUFfDG2JcgJqmwcjfbsMSyvZVDsCjcqyD7TPuPnkVt uRQXZeYY7b9AfdcQq9I3+yortsRv74LC0eioeTjbfnQH5V7ZHkm3emskvEfBx+Eb1rTG6CgWVzBm oE+Amgbt0OAMjzW0IYjbbqR45hal2WjFRP8AWXr0zEctegFMUoq0FZfbJR5oKZDLWK4YpbxV2KuG BW8VdireKt4q7FW8VdirsUOwJdireKuxV2KtjFW8CtbYVdgV2KuxVvFXYq7fFXYq7FXYq4DfFW2x VrFWsKuOKtYq7FWjhVrFUr1H7Q+eTAaMjtHAGnTU7u5wdWwckLTY5kOLLkWuIAwtdABojaoG+SVI bYf87DqTdTSEDuTRP4Zmj+7Dg5uab9I140avxEgUO4p9rK2k8miVIA9tif6nCgleo9MBj1Zdqe3U 7ZE7s47f5y0BuoHyqPHp8JwsdwUZCEdAjKQa/E3t22ys7FyMdSFEKzKu4J5Me3UZFuICjIx2iI+H +UdckGmRN8P8KkyszdKlRSo2oOgrhYEElpU4klieO1fHfElAFLisvpmN1qAORIpsaeIwbMiDVFRA oR2Y9slbWA//1pGCVLNKvFCWq1DT4um+bL3OibTgIo5Ihxbfke9PfE86KtqkrmoNQo5D3UdcbAUC 17q7Kyj4WQHka0670OAFWi4KqKAAAAnoMNKd1/HgeRAI3Hv0wXaFWN6cSXpxXotciQkEtr8QMgGw 3JA6E9FwFFHm2qNxHE/GdyfcYCWQC6qkFT41UHqSeuLJ0pPPdq9KClKUzAznd2+n+lw6ZjBvXr9n FBRlnT1NvDJQ5qUxGWsW8Ut4q7FXYFbxVvFWxirsVbxV2Kh2KuxVvArWKt4q7FXUxVwxVdirVMVb xVrFXYq2BgV2FXDAreKuxV2KHDqDilzdcVaxVxwq1irqYq1irRxV2FUq1CvMUywFqm7SDXTJm7mS Qn78j1SOSHfpQd8yA489ltDkmumwWpgRbH7CKQ61qc60FHiStfFeVcz7HAA4GTcpvQGrBuNKADfp /k5W00veNxxqARsFP8cALMwLSqAxoar9nf3FTiSoDTMPgUAhl3Xc7D5YhBKYQrFxUVIYjkzEbEHo BlUi5uKIXJEhY7AEdKmn0f62JKYwFrE4p8fUEmo8fDE7sY1HdRkJJLJXjWoHuDUA5INUj1DkoVLu x3PQjY4CmNVZK0q6xtRiUNKACoIHv2XCwogeSi1CoNaoDVQRWmSDXLl/Rf/XkLtVVVSQqfsDeubM OiXo/wAbAqVoSpBNf+FwEKubhwEaH7J5Bj4+GI71cJDurgHnSrN4/wA2NKuICMOJDjuw3WuBB2Kt yLEB/hLkNv2AFMjSdy4MQ1COJfYgdx741sgXdK7grHSoBUgGm/yyA5tmTYLeS9AwB7sK7/PCi9ly qH2Wiv3G5Na0pXATTMC+Sk394VP2lzAz83a6cER3XqD0bMdvVE6Y2qNsh8ZyyJsoKPGTQuxV2Kux VvArsVbGKu74q3ih2Kt4pdirsCuwq3gV2KuxVvFXUxVs4FdirW+FW8CuGKu3xVxxVwxV1MVdirsV bHXFXNirWKuxVo9cKuxVrFXYVaxVKdQPx5ZENMyu0yg0qT/Xl/4lkf4mQ5KAAy9oO7ZFMLE7LG2G 2SDXTH9MUnV9VbjUetGCe1QlBmdL6IuBkCbDjxoxIIPQbjK2psis1V2FRsfD/P4sHRlzkvj4qeUr U49WA3PYBcB8mUavdcZKyjmG4D+7DEcgf8o/62IGymVy8kbGWfiWFWYk8eg260ysuZAk1bYCrMu2 53NT/mMB5JFCS2SIRqxaux+zUdPHCDbGcBEWhSAW+EmjdFrUgjJOLsTsuMbMzUHLpQD7jT6cFthi bWksF47Gu4pXphYHkqKkcaLJc7INkRd2en+T+yv+U2Dc8myMQBcv+k3/0JHG1DzYkxnYEbGg6HfN kQ6JWjReDOKs3Fq896k9Ps4CUhTRvg2T4mJ6eHhkiGJdMKqncVAOMUUrpNEsckPAmQkcXBoKH7Sl f2sgY9WXFUCP4lQ8SCRtyGwpXIoJXj0+KA7yEcuXWhWvwf7LBu2GqWqDsV2B3ftU9OWFC8xrt6ZB XxIORvvSY9y/443LICAykbfZ3p1wc2QsHZSkqW6ClT9np2zX5vqdvh+hepHTvlLZa7FKOsd2JGTg go8ZYhvFDsUt4q7ArsUNjFLsVbptireKHYpdirsCt4q7FXYqHYq6mKt4q4nfAreKtYq3ihvFWsUu xVvFDsUtYq3irY64q49cVaxVrFXYq1hVrFXHFWsKpVe09UZZFqmW9MI/RBp/NJ/xPAeaRyURQjbL mguGSLEFpumIQWP6UC1/q22xulAYmpqEzPltGP8AVdfkTX4I2p1C9/E5VzcfkVRUTmWkU8j13IAG C9mwAXusZOVWZlIHUDoffDaJDquIHXkeNK8cCkI6NjRVK+3LcHcdNzlbmRJFbKpBU0JoxHzAH0ZF tIpoKApqpLr2+YwqBQQjKPUHEU2oAT3PucneziSjvsqwQlzxowYCtdh3/wCacgS2Y4Xtu2ZYrdWS 3USOooXYVWo6hE/a/wBbGieabEARH1INqvVj8TsKlvb+GWuLud3/0ZLAhBUuaRkUqp3r9ObKRdFs q+oOIWpZgB4intkaW1gBozFqLUD3+jJWxBVAnHg5AL1+GM/a+eRu2dbW2ys+715cj8XT/hv2sQaQ Yr1clSW+1Xev8MFLzcgLFlpQkVXErGK+V1ZlA+2ooelMiAykbVeQRvT+yUJHH+ORq92ZNbLuLLFV jUVFD479MF7sgNlJtyabLXYZr8v1O2wj0uUAnrlZbqX4GKPsR1yyCCjhk2Nt4q3irsVdgS3ihwxS 3ireKuxQ7AlvFWsVbxV1cUOxS2Birq4q6uKu6nFW8CtYVbGBW8VdirWKtjFXYq1ireKuHXFWz1xV 22KrTirsVa64VdTFWsVaOFUovqiSoPTbLYtGRfp1f0PU9Sz/APE2yPVmPpUgtNsuaKW98LB3Tf8A DCqQ6IgN1q7Mf+Ptvh77D+3M7IfTD+q6/IE4iLgcot23LVoRv/rZUfNhAkbhyuw3rXpsfi3HSuNI EjzbKRqNmqtKAKKbn7XLBbIgLvTo6gt8Q2+fZPuwWyMaIRKq3FUIHJalmPUU/ZyLfR2Co4YUAIK0 HT3/AGcAbZW5V2+E1J+Hb7R74lACj6OzfHSEUcuxoo/q+G2rg8/S4yqaRxAiPoWP2j23X/iOCkiY PpH0oY0EhBJ9NPtceuw6jJuPyNfwuRAY2VgKnx74k7rEbU//0pJHC4SMR/tBjWoNKdSVH2c2ZLoy FYp6cbSAH7NWclQvI/ZHEfEGpkAbNJlHZwjBHxbt9qnyw21hoM3MFRRl+ycWQVqyHhx+Iiu3Wh/a yOykk8l5pKFqtflg5JBtUHBZVLsSQOgA5cd+vH4cj0bOIA7qTXEbEAKaew3+nJcJDAlcrK7Mzt8d dh12wHZI33Kpz+FU8DXw+nIkMhPkFM9T8812Tm7jFyXDj9OVNsiuxQmNiNjk4IKMGWMWxilvFDsV bwJcMUN4pbxQ7FLsVdireBXYq7FDsUuxV3yxVvFXDFDeKXYFdireKtYq7FW8UOxVoYpdirsVXDri rj1xV2KtHFWsVdTFWsKuxVo/wxVJr+pY/T+rLYtM1ay20YEb15Ee9WOAc2X8KiKkVy5o6LT1wsC0 248PfCGJSDQa+tqrMAVN24BOxJr+zmfl+mH9VwT1tPTGQ5ASjOK8Seg/416ftZj3szqjVfUs9GQ/ ZUhG69qewrhtq4CenpVFipQA8AFp8RFK5EybBD/NXb8lZZF5HrQjt/zVinqN4o1bcxojUVgAdwdy a9e+V8VuWIUuEbMFCg8qhj93vgtnw2F/pwo1OfORT9hadfAt0GCyigg5+Mj/ABOoVT8KMQFAr23+ 1lgcfJRPNoWx5FvUSvZuQA+Zx4kDF1tatp14SI/YkMDSuJkiOK+R4mnWCJav+9YUoq7Af61cIsrI RiP57//TkquATxHKm4X5Zsi6FVaGRY2opCvswodvblTACGRBbhhYIxFakUXv8xXAZIAVQkcYJldV 2qorv92RsnkzEdt2keONPUj5M4NeZB47+x64kE82Iobj6nK88rBWbnWtBsqj7hiQAy4uLZsiklE2 A+Hl2OHoxPNZGoQ8qBlBp3AOEm0AqlNivWg2FNwD1o2RSSVyKCPhPFSacW3+nIyLKA3DQO59ts1k 9iXeYxUV3HKwGSoBihMrIfBlkUFFjJq3gV2FXYobGBLeKHYpdireKuxVvArsVdirsVdirsVbGKuG Kt4EOxS6mKHUxS3irXXFXYq3irsVdirXXFXYq2vXFW8VDWKW8UNHFWsVaxV2FWj/AAxVJ777R/z7 ZaGmarZ0/QsPaq1/E4B9TMn0qIBHfLWkNkj9oV9++FXMABVeuEMJjuSDy+ZAupOGqhv5QUHXY/Ew p/q5n5aPD/wt1xJ/2Sb8pVfmrGj12Jqfv+E5TsxMpA2P4m3VvSr2cFqk7mndvtYAd0yB4f6zUSFS p7E1pSuwO9cMmOOJC5oWWReS9uQC9OPXBxbMjjIO6Ot4/iXifTCgE9qV67ZWS5kAqNcs7cI6iKtC Dtyp/McHCz8Qk0OSivBRxNSp6UpSo36nCWsUBSFkiYitKqNiRQnbvtkwXGnAluhCDfZjxZe5+nAy 3AWvIixnbk3ZuXEA/IYQN2EpgBbFPNGpZFAqdyQP1sDhIBY48kgLf//Uk6SyV4x0jB6swFT8s2JA dECulaVwQ8zkAio3agPgoxiAOi8RPNZQkvGrMYwTsa9K+GFT5NSAlgoYECjFQTUUwhjuFeMRleS/ CT8TU60yBtkOS8SLFwZQCQa0Y1Br+y2CrW6c4DKFNAAabk0qfi2/ycQkrWZTsgLVNSe2EBBXhmMi qBudqVpXI1sjqFy0LVOysfhr2H9rZGXJtiPUGz1zVz5u7gdl46ZFmvFcDFMbGvpg9DlseSlF5Ji3 il2Kt4FbxUOxVumKGumKhvFLeBXYq7FXYq7FXYq7FWxireBWsKuxVuuBW8UOxS1vireKuxV22Kux Vx2xVrFW1G+Kt9MVcMUupTFDR74q1irsVdiq1u/ywhUk1Egcj4V/VlsebRkRFp/xw7f/AFB+s4P4 mf8ACpVr0y1paNe+FjZcTQA4QiR2tj/lxAYr5qULXU242pvyrmdmPL+q647lNplYH46jsK9fGuVh rmCqSFjGGP2BRa0B23P7P+VgA3ZyJ4fJcCQylCRTpXYjv/scDMbVSIWICIvJRYjTk5G5I2Cr/P8A 7HIXu38IqzyVEnEnCOgEQG4P2iR3b/mnAY0yjkvb+FzBQSxJG/GniT+1ik06Rgj9K9ge30oMQsiA hXoGBRuFdzv8NPHJuOeex4WmjYryAIHY0qN+mNsTHa1vCHlxbbaooCatjZRwxvduTiT8J+Gu4+QG +ITPflyf/9WTFjVo3AQtSSgHiKZsvN0Zb47gSDqwLsN6kYobITixLGu4UdB23wIG7c6gcXIoTQU+ in44YokuhjqSSeIHTxwSKQF0kagKrV5ip26gnbfACyqmxGVcCUcmZSFB2HXt/lYL7lpeI2VipKh1 34k742nhps0D1pVewPv0wIPNeVKp8Qqx6nwGVyOxbcYo/wCcsqCc1cubuYilVTTFmuQmoBxHJUzs /wC7GWR5MCickhsYEuwq2MC03irgMVbxQ7FLsVdgV2KuGKt4q7FXYodilvbFXUxVwxVvArsVdire KtYq32FMVbxQ7FLWKupirqDFWx1xV2KXYq7FXYoaxVrFXYqtboflhCpFqQJLgd1YZcGmSMhATR7Y DoETIj6mcuSgMtaA7Cq1waYQ1zGyS+WQfqd0zOaPcy8kqSCQ3wqQMzcx3H9VweibgqVJf7NdvYD9 n/VypAIrdayfByO5fcHxFeP68NsDHa/5yIjSOOMPMCVU0RV25Hr8X/NuQJs7OQABHdSkmLsrMaOK ECvwrTcKq5ICmszs/wBJFQU4Kh4ryqxO47dAcgXIgNgtepND1FBTx8cIRLcrwBRh0HuANv5gRgZq EleSFNgVp06CuFpndil3FRFRlJaoq3iOn+xyPVlwilrx0IBUk9yNqbDEFZQpY7VqNkU9T4D/AJuy QYE/5r//1pMiuYy5IbiSAjCjHj3/ANXNkXRKjdQU+IcRUeGAJlQaSP4qsao3Tv8AdTElEeaoyfvY w3xAjkrVFKYAdkSG7YjYy+PUgYL2TW7nJcEjYk7jxwjZEjaokkioUrRRRmB3G3zyJAtMZEClsZX1 QT3O/jv44TySOa80MlBTkCf8xkei9XNIWqa8jWjE5CQ2bcRuYP8ASdTNUTu7teu4xVeK9R1GFU0t BSMZZHkxKIySt4FdirYxVvFXYobxV2KXYq3gV2KupirsUOxS7virsVb2xVvArsVdTCh2BLsVdiru uKt4q3ih2KXbYq7FXYq2Bil1MCuwq7ArWFDW+KtHFXYqtfoflhCpHqBFWHsT+Iy4NMkb00q3p3RN vorkY82UuSFqeuXNFt4pJbHjhYlI/KrD6lJT9q4nLU6g8j45magb/wCa4GOW9JsBHVSoqp+2D3yv daFilb0VZDJKSkANF6777Kg/byN9zZwAiz9K2SZppfUoOKLREYdB/XECgwMjI2pR15BtqU3JG/h3 yRaoc7RsPE7cgT2BrlZc2BXFV5rWlepJNcbTQtqSP4SKcuhPsP5cQVnHZSAZhxBqpBIUEbKP5sJa hZ2coBjUUoaftbA+2BkOSmGl3oRQDiznfrty/wBbDs08UipvwIBDUUGviSR13X9nJMJV/mv/15Sr O49QUK/ZMZ6AeIzYuiVEVfS+18fiT0B/ZyJ5rtS5CsVFK9juRSh6DjgO6Rsu9EtFSgVUoaA0qO9A f8r+XBdFPDYWxgqjkV5qfhIrQV6YSxC3mOQagan2uxr3yVbKq1Ds7LvyqAtKECn82Q5MzvyU4lJZ itOdKb+3vkiWMeav8MafYHqAfGSemQ5szQ97QCqjbbkCnz7nIZT6W7Tjdteuas83brxTpgVsdMKp tbf3a/LLRyYq2SVvFXYq2MCt98VbxQ7FXYEuxVvFXYodil2KG8VaxS3ireKuwK3ihrFLsVbxV1MV bxV2KHYq7FXYpdirsVbGBLfbFWjirWFXYq7FDWKuAxVa/Q/LCFSLUBtJ/qmhy4NE0cygadAPBFof oyMebI8kNx2y1ppqmFDZ23GEIKT+VGlGlpwYIsk0zb02AdvtbV5FszNRXE4WMkbD0p4FiVQ0gEgP QL8J8fi/ycost1Abn1KDcriTZuSgUVNwqDwXl/L/ADft5IbBol65bFoEtyUtxY/DUfLEqN7BLaGP 0+QU1Ao3Lu3/ADTgPNMaq0RBUgfDsadfn2wSbse4VW9M7DYk7MBT5DIhtNN8vToJKkGnM9KHxGK3 XNDTgDkUYlOgoNqduuSDRPbcLmFd+zAU7dAOlMDMhYXUAupNG267b+2NMDIDcfxKTKpb4TSnRv2T 88k1EC9n/9CULTYVqe9K5sXQkqgCVHOnHcKfDbAVA3VUAWVQqgA7AMa9fsA8sgeTMc2+LuWRl5OR Uk+2xCfs9ceSaJaB5tIzuTJsVpTenhh5MQbslb6JqFoKn4hX2w8S8LYSSoHdxXcj+GCwtF0YADBn UBtvHCVAVCqb0FQTUk7ggeGQtJp0ZBBJ2boo7UyrP9Lk6Xctr1zW9XahcOtcUr1FMVTa3FEGXDkx VsKuxVumBDeKuGKt4q7FLsCuxVsdMVdirhirsUN4pcMVdgVvFXYq3irsVdihrFK7FDsVdil2KuxV 2KHYpdTFK5cCt4q1irVMVawq7FWqgdTih3Xpviq2QfCflhCpBqJ2kPgpP4ZbEtM0xk+Gwtx/koP+ FGCPNMtghd6Za1dHUrhQ5uhr4GuEIKTeVVD6HCz7UeQgdyTIePH/AGOZmo+twI1IWU2kJRzIBsD8 Knt0H8MqG6Zmt1g9STi5FTWlTtuB/TCdmEblRVvASDftx6/PjkG4+baqnECNg4OxZDUiu32GxUAV QRfoOOPImhUVUnuOgGRMnIEG60NPteI8D44KZNMjMK8gag03J2x5Iqwg5WXjseh48d+3fplgDjTO yh60hUdarsoHjhpoGQkORJHTkwoHNN8SVECRf85yRlxwUs3fjsdx3+HEmlEb2D//0ZYoX4juK/Zq CN+465nui26rkCsxK05J8QUdNz7+2KefJUfgeFFqEHxO3Vge537ZEWsulLA7EAKDRAVqOoB/n8Ml S2aaVSFCxsN+gHxUphPmtN0ZitB8Sk8mr2wItvhXntRSNqd/lT9rG00vhRJF9OnGQ/tA9CO3+yyM jW7OAB2/ibAWoj6SAU492p7jAiujSsAhQihr92U5xs5Gl506p7ZrnbhevTfFBVFO4xVN4fsDLgxV cVbxVsdMUOGKW8VcMUOwJdih2Kt4pdirsVdirYxV2KuxVvFDsUuwK7FXYq7FWxXFW8UOxS7FXYq7 FXYq7FVy9MCt4paxV2KtUxVo4UKE5I6ZIK3GkhTnUUGJQqybw170yI5pY5qFW9Re/Bvwy4OPO7TS Yj6pBX+Vf+I4I82cuSFBBHtlrTbtqYVc9FiZu9D+rEc1lsEj8row0K2c9y1Pb4m3zO1H94XXCNRv zTyJVbgGAcsKg+5r1zHJbYxBq/U5QpJCjjQkBuvsBhKYAFyj0yXcVHZTua+1P2aYOaa4dy2HMhLL RSPs0FKD/m7DVIvi3CLhuJSq+pvQD4hsT/n/AC5WQHIgSRuudd+1H35Db6DgDLqsZuANSR1oOlR2 wsboIYqvU0Kk9D1HyyVtPCP81wPpUotRWlOhoe1cea/TyWmNSCA2670b54UGIWmRY2oleFO53Nfl hrZhxAHb6X//0paylmcgnlQgAePhmwDoiGkRyC/I8hQFT3HTwxJWIX8TI3Hiy8TQHbc+HXBdJMbK 1qcqb+r+0KU6YWBVQwfjzrzOxHSh/wCucg2kgqa1C0rx6jr1rki0jZUoyqKAMDtv2pkWyqclWBJF OOwpX7WEqFwDdQ32RxXofngTuvijkcEMB8/HMfOdnM0gNrXQoeNKZgU7NtdhgVUj6jCqcRfYGWsV TCh2KWwcCG8VbxV2BLsVdireKuxV2KuxV2Kt4q7FXYFbxV2KuGKt4oaxV2KWxireKuxQ7FXYq7Fk 7FDsUrlwIbxV2KWsVdirRwqhrrYfjkghi2rahfwWF2Yrh1AeJV4kKQH3cLtkYpI2Q1pd3kuiSTNc y+qlavzapHEso64TzQxFNc1ZC3+lu4PUSUYH78yKVPbPz3qMxhtLi3hYVVVkQspoPh3HxLhjAWwm NmXRyo2wPxDqMJDjRmOS8EYptZdbW8h/yG/AYY82OT6Up8rFjoVmpHIEdV2IqxIG/XMzUfWXBiSQ nFFenpSAUPxBl4kb/wDA5RyZ1xcirGBwvwxgodxUHbf7IwW3cG2wUuD9KceNa7Gv0VyVtdH/AEqo hZ4WboRQkGnQbbDbInmyBJiiYWDqvLwr075E7N8JWG5aoGdAtTswJoCB3GALLYWEMzxyhmZuNABx boBWtaiuTqnHkQRa8RKzDgVkp1KkH6KNkbbaB5LCj8+IJQgciOgHbuMLGjf81ZMRt2LCrAD/AJpy UWOQocgqFFa08KV398k4xFP/05eiBU5D4qjc79f5sz7dGujkZUrzO9C3fZasBT3YYCN0xkQugLPK WdaEnmwY8T8x/lYJckxJJ3WV4yc5AeKk7jpvvkumzHra5gGAZeoNTXqPDAq6UfEOQ3Va8R0B/mrg CzG9LNmIIXenXvthXmu2QDvU1bvv4jBzW6crnlRiFXcg40kEdUbpwLSBq1AFD4CnjmNndhpR1VNS jSqsNt+n0ZiTcwc0FTK2apF9ofPEIKcR/ZAy5ivwpbGBXUpihsYq3gV2FLsCt4q7FDsUuxV2KuxV 2KtinfFXYFLsVbxV3TFW8VdihwxS38sVdirsVdirsVdirYwJdhVtRTAreKuxV2KtYq0cVQt30r7Z IckMN10/7jrs1p+9gp/wJwQ5szyCFsi40N14mjFifojwnmxiwztmUhVsh/pkX+sP15KPNjP6Szq5 mkjmUo1CQKnMqMQQ6so6y1SKSkc54SHYN2OUzxkcm2E+9GXbD6pN4cG6f6pyuHNnk+kpb5VZv0La gj4TGDy9tzyOZWo+suHiOyay8WcKxYxfs7g7/wA3HKhsynRO/wBK2KPidyRUgAciNh0+zhJYwjSI Ezp8Mq+qrdGI3H+yHWmQq2/jI5+toCEVMikqQaO23T+XDux9PVEwSO7BVQcAo+KtBvkZBtgSeX0q 5QPEadAe/uMhe7f0QTpwUcRUVqCfbLAXHkKGywqlOJpy7A9if8vCwNcm0kl+JlYiooFB2qBt9rAQ FBLQkL0WRAdt2TqP9Zfs4qCTsR/pVMEs3OM/3XSvXrh6NV2bH8D/AP/Ul6h1BUNUHavT9eZ7o/Jc E58glPgapJwWvC74iWaQg9utOv2sV67tyJVQU6b7HqAfHxbEFZBfwUANWoFBz6E4LZTDUgYElTsR XiNhiESDaLxYEEhVPEUPWu5xJWIotzFWIcnfpT/V6/rwRZTN7rEEe5pSlCB9OE2wFMIu7y6n8wGM SOEMyqsYYgdaceuU5+TtdPH0sltZWbWdQ+I+mpQKtTQUr0zCl9IcsAAJsDXplSqkI+NR74QhOU+y MuQupgQWxil2KC3ilvFDsVbwK7FXYq7FLsVcBihdgS7CrsCuxV2KuxVvFDsUuxV2Kt4q7FDsUuxV 2KXYq7FXYoXDpgS3irsVdirW2KuxVB3mytTrQ0yXRDDPMLf7j5FHU3EYp7eixXDBkTsh7C5Z7EwU 2WORx70SmCt1jzYa/iNq9RmUGPRW00D6/By6chk482EuTO54SWHypXL4l1uRASRyKxAbftloLBFJ cXAt3iLgclYfSRTIGIu0EmqUvLt1dWjR6LdBWTgzwTq3UJuysDlmaII4wiMv4WTRxHdePGSgo52G 5+z/ALLMUlsEen8TlLrVNhRuRFKgf8F8WJRGxt/SXSPIHqhYAUG3U16UGAM5yN7KU9xKqhh8XxDY qCK13FcnEBoy5DVphbPHJxCgJQU4ncAezZVIU5uMgjZFlKQty7nK73bq2QbKta8RQbH5HLGqlCVU PUfCSNh49MkGqYBWelxowBoKbfRjxMeClRVJZjGF4E716D+bAyA7kKY2I+EcV7E9Tk7cfgJ5P//V l0zsxYEcQuwXvXM+IdHI7rokKGiipJBfsRXb7WAm1HOlwVTIrVID71ruBXG9lkPUF0x5yeqCWYtx r06bYI8qTM2bXM1PhQ8KNy+LuvT3wAM5Fa0m5DHjXeta7jCA18VuBqzFgTGQC29BU4sgtpxIHNXr UnjX/hqj7WFhy/pNooCb/aNST8sBLIMAiPPzFGf5rha/8FlGbq7fCPSGU6Z8d/fv/wAWAfdmFLkH JjyTgDvXIKiLfeVcA5sSnC/ZGXobxVumBW8VdihvFLsCA3irsVcMVdilumKu6YobrgS7vhV2KuwK 4Yq3ih2KXUxV22Kt4q7bFXYq1UeOKt7Yq6oxV2Kl2KuqK0OKrxgVvFLWKt4q1TFVvXFUHe/YYexA yY5IYlrdu9xY8bZGnZ7oBOKkH4IzG1ajs37WMdiqn+idQttJ5XEDo6wycAAC1WFN/T5HDW63W7BG BHXYjrXb9eZARaJ0oB9QgHi4ycObDIRTPbmQFgCNgK5bEOsmbQbNFyHw18ct3YA2urD/AC7YKKlZ AQ3mG0KAUSCVt+lNhln+TP8AWWJ9Vspcn1F+OrbcVqSAP5V5Zhjk5JFHmpyCIsCzbVoo7mmxrTCL azwk2VwAaoQ14nY+47jFlz5NtGJAoZRRTuR99cN0gwugVeBqEAqP8/HISboI3iVhPA0Ynt0r8sr6 t3RCPI4C84wX33FQa9O2WU0EkKRli5qrrICOoBBA+/DRYcQvfiXvGrKOB5En4aihHzrkQW2QsKDV RRQcRWnxbbHfjTJNR2DdUG5NAzBga9x+rFdg/wD/1peXLSMyDan2QK9PbM+tnR8yqMeR4ULMKFXH cqeQbIhkea9Y3LGZxUV2A2oW7jpgvongJ3K11Keota0aoHfCESDSlhQbqKYWFlYjAt8ugpWowlgF 0vEBfRJAc/ZbckDIjzbZV0XMoHxtUEjYeONrXV1y4KBkIHwbqBQg/tYIhMyDVPP9NAk1+Pv++5fd vlGfq7jD9IZTo1TNet4zNmFk6Nw5JyOmQCoi2B9VcI5oKbr0Ay5DdMCG98Ut1/zpirq4obxS7Ah2 KWxirsVdvirYrirjXFW8Cuwod9OKXfScVd9JxVugwK1QYVboMCuoMVbxV2KHYpdvirdcVdirsCXH FC2T7Fe43whVQbiuBW8CuwpdirWKtEYqpSwiQGuSBQoLa8DVdsOyqsxPpGvXviOaljl3bWzsQ8KN UipKgnqMuDjSJtfqnlnShLFcWVtHBcRktVagN7NTHHM9WeSNhCTQyk/GvpyUpxHxD/Y5kxk4Eo7q LRcRXv0OWgtRFLDGaUOG0KVgh/xFBRfsW77+FWA5ZOX92f6yw+pkvJ2ZBXkRsF+nrmL0brJIbFGJ BHBQdiO/8wxSKP8ARXBkECoN6V2FegPVseqRIcNNoeKlQ1Cfeg3xLIbClYcgnByGqeu9Nu+2RZb8 ijojWMb1+LemVnm3DkokrUgkUrSp8T8WSYodggJLj4j4mgqe2SFsJV1UeMbl42BLD3qKk/aXj/Lh 5NYAJIaL3BB9NqotBR9xWnXkcOzG5XstE4r+8iHFV3oafg2GkeJ3h//XmaMOCgAD+am1fm2ZpDpB LZtOSlaNUgECpqV2p8OApBLTQVcq3wrXoe1PH3wiSmFyXRGEMwYFlU1ofbb/AIbAbREiytPFqsxY DcqnYA4QpILUC8aAniT0I6dcMjaAiXiVEDOAoBIp3of5f8rKwbLdKHCLKHkEZo6nr2FTQe+TFtMq 5qNw54vRTzZSBTp0yQDG92O+V/L1/cal9f8A3a2sUjB+TfFyoR9n6cw9QdyHeY/pCdabZTWnrJPx 9R5XeqnkKV2+LMKZ3bhyTEdMgqJtKmUe2Tid0FOEpwr37ZahxxYtjFLsVbxS7FDeBVpYDYbnwwq6 r9hTFW6NXr+GKXfH4g4FbBPcYq3ireBXYq1ireKt4q7FDsVdilvFXYq7FDsUuxV2Kt4q1irsULZP sE+2ISqr0GBW8VdgV2FLRxV2KtYq1TvhVRuP7s5KKCkNwSXoBvzUf8MMtDQRZTa9+0B7fxwQZyQj KrfCwBXLGkhQntQasByp4dfuycZNUsaW3CMlGUVUdW7ZfHdxZBD6d8fmYfEFVbRw1durDLZisX+e uL66ZIz1CnkCu1DQePX8Mxg3yKkwNeNCd/iBOxJ8BhaiN1RJAprUiq8WPtgpsEgvV2JIqSoNG2G/ YNgZAq8Sim9WUb0O3XIltARJYBCpFOnEjIslNuYoS3wkjkT7YUFBzTMJKgEnqPkcmA0TlRaWjcyA Rz+xvTrQfETiVjva0BaAgHeu/WlOuKilFvhanEGo2AoK1Na5INMjR5P/0JmOSniVFD9seGZrpKpp qbxmoCAiqjqffFTydGGIUvUBgdye43/ViUDcbqipP6ZUio41B8ATgsWyAlTSpJw6MT028fbDYUAr iY4ozvVido+qinflg5lJqI/ptTu3wo27L1ZT0BxiFyG9ipqAeJ5dTQDr+rJFhEW08cJl4yCqndIe 5B7H+XEE0oAElK3jSC2a3tlMETMWZFYmhJ3+Prmv1H1u4wS4huqotFpmM5CovTAqMshWTJQ5oKbf sjLUNYUNjAreKuxS3irTHb54obCgDAreKuqfD6cVcDXFWx9+KVzLSmBVuKt4q3irWKuxVvFXYq4Y q3irsVdirsVdirqjFDsWTsUOxVbJ/dnEKqp0wK3irsVdilrFXYq0cVartiqhcH4CMnFBSKaplUVp WVf15aGgndNb3dx8sjBlJD0yxhTqb9N8KEu14tDpd3cwnhcRRlkbtUfzZbi3kA1ZICrW2Ftat6d8 /M3ckSoZFHw0YB2oh+z8WXSkfp/hcUCPP1cSaxwJRnG5Jp9HyyklvjAc1iRtypShG60J6H6MNsIx 3VRHUAMoQUNWIqfxyNtvDbSgqePH4SRzodqjp/q9cLGqKMi+JV5U6A06k0yBbhyXEryqNjTfFK1t wAa0JWlP+JYoKGm4cwwYsSaAUNQvzyQapValwkNSKsoNd+nif9kMlbGi2iLUiQ1p0HgvtXASoj3t FUUVROTDcb7ivbfbEFBiByD/AP/RnBkhSLijeo9BVlAAU9aKcy6JLp5EAUPVJS9SPgKxku5INCeX T9o/ZbJUWBkKXM0ZjAJZWejAFR1J4rvgANstqbE8ikJx4P8AzvU/8Cgx4UidbdVJnkeTgXYqTsN/ 9lVUyQAAazIk817OGck1c0oCRT/PjgrZTzv6lixgvxJoTtGOoJPQfjhJ2WIuVKknpQEIhBlr8bCl FI6gYBZZyqO38Sxmnohah5NUMBSpBx2RZbkCnp7nNdnO7t9OPSGl6UyhvoL09+mKo2xH7z5AZKA3 QU2/ZGWIW4quxV2KHUxVvAriK4Vc7EsK1oetMCuCLUVJGKtsQOm/hXFXIKDf54lK8GnTfArRJJxQ 7ClrkviMaVvArsVb3xV2KuOKuHTFW8Vdih2KXYq0/wBg/LEILSovh1xtK/FWsVdiq2T7BxCqq9MC t4FdhVxxV2KtYpaxVo4VULg/BkosSkjD/SI695Vp9+WVs0kepMr3+8Hy/jjBlJRHTpk2LXfFilnm JqaHfE/76IH00GZGm/vItWU+lE6dxNjbLQj90gFOteP7WHJ9R97TjogImjRnmpIB2Umla/6v7WR5 ry3a+sTigLlVrViABX7sPCGPGe9UW5kKgNVlpse/+3keFsjlK+I7MVowr8VBWg74llABGAtRT38P b55BtLaLQAEfF4eHzxKQskkdFJUbeI3qcQGJKGHqO4DUDfSN+uSLAEnmpgqJTyAPIUA3ANcPRgee /wDEtUkqAAQ4qrmtcVjyrqtjkLVFau3QfI/tYSGMJ373/9KZW68xQ0HEGm1W37f6uZ0tnSQ3C1A3 OhNB1qMSxDfUgqCSDQKMURG9qyxAMrMrMKhdt9ye1chbYI72saqI03R2JSNCN6ftHJDfZFVcm41E sRQfu4R8RY7AEfa40xJosojiH80LRLGBxjHDsr1q3+bYaLETHRYGkbihHFKkD59TXDsiVmlxCcKq 3xAdN/HwyKnYL592qNqfRmszc3eYfpU1r1OU22Ko6YVR1gPjPyGTggpoTsMmxW4UuJIFcCuqx3oM ULhy70pilvAh2KW8UOxV2Kt1xV2KW8ULXPwnEJbUDbYYquNMCHYpdUeNMVWh18caVd1xV2Kt4qtL qDQnfGla5r74aQuBB74EtSfYOIVeu1MVaZgDtucQq0Fz2/HFK4GvUUOKrZPsH5jEIVR0wKuxVrFX Yq7FLWKtYq44VQ1zsmTixKSn/eqH/jKuWdGm/UEyvT+8A9sEOSZlQFaZNg3tiqU+aCBoN6B3j/iu ZGlF5A4+pNRRlmgW2hFeiI/gAOPHdVwyNktIjW3+eianlxLEqRQkdKD5/FgZ+TSRivwUAqAOXShx tYwrk2FHwno3I8U7U+eBIG4VUhAYlyKD7PHrXI22iG6JV5CRWjfMUwM2/VVqoagkCprX78FIJalV gnU9fooMQVIQ8ySE1Clq0bpuCK5MENcolTkUOFPH41HQVrse3vjbGQ4gGmIElBuDs4O2/wDk4E3u tC8VLEVQdD3/ANUdMkwqh/Rf/9OZRqfTkCb03O1OmZxO7owDRppw3ErU+oKdx33PXEI3VFjleNmC rWoBblxpT/mrASA2cJIK9QW4qSDTcFeoVfHIqN6XFWdzypHAnw8tqfEa/wCydseQ/pMyL5/RFDzy uz0VfTiGyovSnbb+bJxDRKRPL0xWFa02oRQgnffDbCiF9ZGb4vip8TexpxwbNlkucigC7v0Xw/zr gC8xTcrFpK9jWo981WXm73H9IaGQZr1rX2wKOaYaf9pvoyyCCmbdsmxaxULW2U+J2GKrgBiq7Al2 KHYq0xIIA74UtqH70wK2xoCcUNAMepoMKuJJO2w7nAq8L8PvilZTkTXsemFV4yKthBWtTt2xtVrN QUHXthVwjr9rc42q6ijbAruI7Yq7FVrEk8R9J9sKrlQDoPpwWrZI7nFXcRirUo+Aj/PriFbGKtha b4ENE0PTr3wpbAwKtk2FPcYQqqOgwK3gVrCrsUuxQ1il2KtN0xVDXP2DlkWJSQ1+tWx8Z1r8q5YO Raq9QpM7unq/QMEOSZKNR0AybC2upwsUo80D/cHdnr8I/wCJLmTpf7wOPqR6UziANtCE+ENGCw6d BTc9WyPUseYVWWgVq78hUU2IpTFJC1RTYOOI+2DsAe2AoHvX0VkNBUjcV3p7DAzIBDmJDcgCB28e nhigk3aKjDVHI7gg1oa1ORLeF3IknbcmoHUV6YFaLuvLiaCmwO+/fpjSlDyNJT1GLHbx4gD/AFRk gGqV81Np3TcMSNjRlWte/XJU1mZDonfdlAJO/wAQ/iMBZRJ5oaRpCxkdtiKBuu3SoGTDjTJuyX// 1JopUMEPUblnJWp/1czC6Uc6aVwxKvGrbnCQgHyWspbqdmPSu1B0rhCLtWciIKJqsSKqBttt8Lf5 ORG/JkTw81C5cysWJBC/ZVfsfdk4imrJIyLkYsRRgpp9o7KPbEhMd1yCRGNQATsa+GA0yo8nFFI+ FviJAb78bXhXRoFuFjI+JTs3bATtaccanTU1eZr1rvXNTM7u8xbRWg75FspUXwwITLTqEsffLIMS mRyaFuKWur/LFCo68FXs3fArWKt02xS7FC1h8ajClUXvkVWP9k4QhcBsMUrivEe+BDq7U961xSsc UXbxwhV69sBVx6mmKrF3Ynw2GFVXYL7nrgVaSp7gYq0h2p4YlV56VwKpoK1buT+GSVV6L88iq07i mFS5QQKdcSrUp+H7v14hVy0qBgVtjXbCqx/s/KmIVeMCrJB0+YwhVUdBgVvFWsVdilrFXYq1irji qFuvsHJxYlJVq13b+Amr92WnYNOMpnebTU9hghyTIqFPxybAt0wqk/mkkaFd0/aCgf8ABLmVpP7y LjakeghNYPijhULWkY2pU1oKnj/LlZ6sR0/qrgoC0qfhqTSgNB+1vjaejZjUH02YFj0oQRvvUnG1 MRyXg8lcjp0r22+HamBsBsLq1ohLDYd/DbAvkiqqGVuXwkdPkMi2W5QKkdQN/DAhSYMwY0p0p9Nc kgof4mZux6j55JrskrBCzSKrAb9z1w2wMCTu1Idwo5AHrv1I70xCyPRRd/hEZAULVQenU16YaapH an//1ZtPJzdTKgLbUk33Ir8TcszIjbZ005XzUAOcrGlNjRh9knJ8g18yjIYkRPVY1UEBBT7RHzyq RJ2boYwPUUPKJZ52kI5MASCBsMsFANMrlIlDqSKjx+7bJlpREca0UM1R13Fd+uQkW+I2bHAu1alt uJXrTB0SKtfxVRwUNyU8q0r2wMi1CpV+RIPqe+9Pf+XGR2XEPV/WU3/vCO2/4ZqZc3dw5NDrkSzV F+1gQmenD4Se5OXQYlMTklWnpihydie+5+nFV0jhievtiFcvTfAq7tilrFVp/vB8jhQqDocilY/2 ThQvTqMSltjVjgVrFC1+n0jCEr17YCrffFVifZ++v34Sq8qDuR8sCreKYoDe3bFK4/Z2OBVqfZGE qubArWFWuS4q0+4+kYhV69cCuPXFVr/Z+kfrwhSvXAq2T7QHuMIVUGBXHArsKuxS1TFXYq7FWj0w otC3X2MnFiSk0LH63bqw251Vvc5YeTRA7pjd1M/0DGHJlLmo0yTFvbFKS+bCRok1P54x97rmXpP7 wONqfpTii/u9iCVAB+gZWGJA2VYwqho2Gy1AK9h03wFlDbZTdCHBoNiKeNe/0rhBYSG64OAGT4gV O4/EnGmYl0Xx8SSCRyO1a0NPH54CkInip3Ub7Dr/AFyDa4mppUgk139tsVK16iPkTWm+/sNsIQUM RWtCKkbKDv8ASMk1rhy6yLRQK171GRSCeqhLWoZht2JGwrkw1z7ypseZ5kAClB/XC1EcW7//1puK yTHsv7G/IdumZnIOlPqK6GkcpU0DAk8QdjT+c/srgluGeMUUNLNLLMZHCjkPsioVfllgAAaJyMpN qzGMkOaDZiNtiCKn54kbpjdN+l6chABUH7Ne+DisIMCCvt6ASFqBqEgnalPAYJNmPkXMSx415cRs QAD/AKuIYS5qvNXlJZfUY7kHsaUXpkaNNomCf5y3ivQH4uVQOwp1wSOyxjZrrxKLseZ8K5q5c3eB w33yC2vU74pTXTh+7y6PJgUe3XJKsbw8cULwvwhu2Kl1MCtV3p3GFV3XAl2KFv7Y+WFVQdDgVY/T 6RhVemRKuPXFXYqtfp8yMIVevUYEuPXrigLUqKjCUryfHtgVosBucVaHMjphVdxI698CrY68aeG2 JQvJxSVhYdF6nChciDYd8CXS0otOlcQhcvXAlo9cVWSdB8x+vCEFUXAla/2l+eEKqDAreKtYq7FL sVaxVrFXHpiqFvPsZZFiUmiI+u24P81ctHIuPH6gmF5/vQaeAwQ5Mpc1IHrXJMXA4VSjzVvpHH+a aEf8OuZOk+v/ADWjUfSnQRAFDEVqCK/dlQK8I2XAqWf4uPYVHgThUGysB5uGam5rv0B98SxG5tUo qMW5DmenXceGBnVFoMvqgGoWtar12/Zx6IvdGEVJAFK9+hyDcVPqVAI3Fd9qDJMVk0PORN6cOx8a d8QUSjdKJ4hxxNSBsR2wsOruTPUrTgBvXYHfFJ3UaB3Kq3KhoD45Lk08zspzLwjVN6bgGoPU/ZIX CObDIKjT/9ecy3LluQUFq/vJVFAVI+yv+VmWIuplk/6TWSLwagABcBnNdjXtT2wjdhIUpNxU0pVK deuTDXQtuZPhJC8Q9ONPAYIllIL0dgoZd2Hwmu+/+SDgIXiI5NsgIUmlR9oH36YAUyFBt4wAhK/C 1Sw3DU+XuxxBZSgNnJEFcCpWm7MN6j2xJYxhRXJ6Pq/CxIIqSRvWlemQlfC24wOMUhjQkk9c1h5u 4iuXpgPNNL064ElN9P2jHvlseTAo09ckhYN2J+gYqrORxVQdh1+eBVmKrT9se+FV2BV2KrB9v6MK qg+yTkUrGG30jCheowFLsKuwIaatB7GuFWxuMCVwWi1xQFpBBBH04Ut9cCHBFrWmNpXig3wK0Wqd 8KrDUHkPuxVsEH+3FVwHhgVuoGKrG+KnzwoXKRXFLuuKtMK/rxVeCOp6YFU23Ye25wqVUYEN4pax V2KuxS1irsVaPTFUJef3ZyyLCSUQCuoWw+/LDsGiP1BMLredsY8mcuakB1yTGnbYoSfzTU6agHUz w0/4OuZWl+v/ADWjUfSnkQWRg4Y8t/hIFB0yrkFh6ja2gDHk1GO9Oo3wr1c/JOKgtRh+8A8DuPs4 jdjKxTgtacxsRUUG4oaYp969FRxyDUApUb9a4CWQAO6KUAr8R7bZFscRUfEARWpG+KrJaMKbLUfE N+tcQpQ0woQUNdutKV/1cmGmfktn3Mag8FUUYHx8RjFGTegsAHY1A+FG6b/0wsaWAhgUC8uJYjwP LvixBsU//9CbmM+oIkclG3Cj7I6ewXtmWDtbppRJNDkh2PqFmYFQDxBpsR/Nlg2aiqH4owUH2RQB jT/P4sHVMtwKVCHZPTBUAUaPgdtx8Va5FuPKlIBi3w0AFTT375Jo5nZxLFKEHboOv3Y9WJtWVy4J NTx+1406ZAinIjK1RPTGw+0CeINSd+lf9XAbZig1ESSxHUbH6O+RycmWH6kH+03zzWu3Xr0wJXp1 wFCcaeKRLlseTEotq1NMkhpRQYquJxVwxVrjvXFV1TgV1fHFWqb1wquBNKdsCWtvHFWw1OhHhih3 IeOKu5L44q7kvjiruS4pdzHjjSu5jGlb5r4Y0h3L2OCku5e2NK7l/k4VdyP8pwUh3I/y4UuDN/Lg pWyXPbFWvj8B9+Kt/H7Yq74/bFWvj8cVbo577Yq2q0Hz3OKCq4EtYq7FXYq7FLsVaxVonFUHe/3Z +WWRYSSuAj9JQAihqaU6dMnLk0RHqR1wf37Vwx5Mypda5Ji7c74qk3mepsrdR1a6gAA6/bzK0v1H +rJxtR9KdpGBLuCRTcfPK+i8Pqd8NV+AAmgXc7j9rf8AmxR15LwtCCd+O4FaV7UwFspr1ZA28YoK 0NTXfDSOI3yXK4ZCQNjse9KH7WCkiVopFU1IPbffIlm0AAa1qxoSakbYlQtf42YMKHxxQd0KbeVq ggKg2DMadPnk7DQYH4LDCAFaR1AU0Xev+V0GNqYDmf4WmljMvBU9VkPwFtkA+R3w1sgzBNAcUood mcq3Jq7049AOv7IyTSZGt3//0ZtPI/AxoxACio23/DMyI6umlM1QQ7NyK70FRRe3+rllU0g7qrRl pSeBAXdl70yAOzMx3V5RFsBX0uK0pQleuzZEEtswP81T4AEgt8NAQ30Vw20iIBWoJOIotUY/5thN MgCQiAduBPJqEK1OlBX4sg2jlTTAEkjw6jxxUtAABmpRStD8/HIZOTbhHqtBrQZrXbUqL0riq9Ou AqnNmKRLl0eTA80SanetMKtUPjihdQ/zHFXU9ziruPucVdxHicVdwGNq3wXG0u4r4YFdxXwxVvgv hjaG+K+AxS4AeAxVugxV1BirdBgV2FDsCt4pdirWKt4odilvFXYpaxQ7FQHYpdih2Kt1xVfXArsC uxV2FLsUNYpdirRxVBX392aeGWRYSS63ob+Gm5qf1ZKXJqid0XcH983zyUeSZLBxyTEOqK4raT+Z TWGxps312Ch+RY5k6bmf6knH1HK0+X4VLkbsfhrUbnKmZ2WKqMojKcGJ+Fzvud8k1jcVXCuCGhYE kg7A719sSzpsxJEqmaQKTU0O5NMFk8kGo8y4SoFIjUVrWrHrXuFxpII6IlWk5Eg0HQLQU6ZCmbqt zBenSlR3OFKmZZTvRFPStST4Y0xspfcRsWPqPyYigVtwTQdMtiXEyR33LSbDiaLyoxam9Kb0piVj yr+ctNGqdmdyQR0p/nXFid/fNZJQAFqsKkVG1SNqYQxyct3/0pvIB8QrVzt/scyw6WX2qLqiKDXp 38MmCS1yFLlNWJY9R1Pf7sSoJbD+oDUkED4TTrgIpbsOMbCJSwPAHfalf+bcN7rwkRBVxJVRT4ZF oF8CPfIEbtwnY/myaj4s1H6/sldxv44lENzu2xCkIgoO5JPbAyujQW8gYH8B37b5DLybdObKEC+2 a1268VxSqpTAWCdWv92vyy4ckFEYVdihvFXYq3gV2KuxV2KuxV2KtjpireBXYpbxQ1XCobwJdTFD sVbxV2KuxV2KXYq7FDsUuxV2KuxV2KuxVsDfAleBih1MVdirqYq7FLRxV2KGjiqCvjSInLIsZJba AfpCGnvXx6HLDyaI/Ui7j++fwrhjyTJYOlcKHVrilJ/MVSunjt9dhr8vi6Zlabmf6knGz9zIFZj+ 7HxE0+IjuDsv+wymurO96cXhiB9XeSpqNyR4YaJUyA5qXqzunBGo42AptTJUGviJG31LSGWPb7W1 XrvWv34jmg2A1FGWf2U70GEohHdH8jVghoo2PSpypybaINKhelDWu++Kqcqj7YqT1Hv92EMZIR29 RlNF47sQ3t2OTGzRL1Upqi8iWO3VRTbx2xJYRjvup024jarVFduvvkmFLnAZh2PLam/QdKYAyluX /9OckckEvEHajE1FO6f8LmX5OnIv1KBVCjMWJaoNKdQdtsm1mII5qkscfFATQnqe1B8siCWUoil0 UdXAWlFAGw8RXASmEd11VUcCxJNQK9QPYNiy5KccdeK8gRTcg9D0GElqjDzVY1EZZOQp1IPQ5Em2 2A4dl4DyKjMwqi0p498B2bN5UtkUfVmKihNOPh175VlOzdgCCU0qD4n9ea8F2RXr1xQqINx74VTy 2H7sDLRyYq2FW8UOxV2Kt4Eu2xVwGKG6YpdTFi3SuBLqYq3Q4rbt8UuxQ6mKtgYq7FQ7FLqYodil 22Ku2xV22KuBGKGyRilqoxVuq4rbqrgW3VXFWuS4aVvkMCr6+GKurirsVdirsUtYq7FWjihAagaR NXwy2DCZ2QNotNQiPehP4ZKXJqjHdETf3zfM5KPJMubXthQ6mK0lGuozTaYg35XsZ8OgOZWn/i/q ONmG4/rJ6ZghrHRmGzN1UHfKQGZn3KRALEOTIXINe+2TDWRvv6uJqMRioBoa0pTsT9psSiFBfLyK VRTxFFWvfxwBlLlstUNTiG+zuVqa/wCtthtAHRGorHr26V9srbg4UY8SKdsUqcoZfAHwH68IQUA/ LkwO9AQO3XLHFN25AzlVFKGigkb1wFkLOynKFZlRzxKj4ifDx2yUWvJRoFSUHagqxOw77ZJpAf/U nUUbGLlx3JFFO23Un/VzKJ3dPCJMbbqysTVVAADADltXqPliyshYJOalmHIUqSRTYmm2SqmAN3a/ 00DABqEfte5yNsuELBIeKq/xRn7NKbYSGAybUV7LWMN4bKDsd/HAObOQ2t0iEJ8QI3pyP8MQUSBA 3XqqqSitU7AfdgLYABsGpwVhkNa8iu3hlOTk5OEboAAV223zAp2CoMSg81e3Quw8MIVOoiFSmXMF TmMaS7mMaQ4vjSu5jGlbL40ruftjSXcz4Y0h3qHwxpLvUPhjSHeofDGlDvUONK7mcaUu5nxxpLfM 40gu5HFXcjih3I4pdyOKtVOKt8saVrlirfI4q7kcVdXFXEnFWqnFLeKC7FDsUtYpdXFVRJO2AhVY UORV1MVdirsUuxVrFDTdMVS/UP7tvllsWufJBWJZ9SSopRdzkpcmMNyiJd5X+ZyQ5Ilzawq7vihJ fMI/0jSf5frakjxorEZl6blL+o4mpNUn0hABJ+E0JA2oNuS9P2spDZI7NOVYBkJU1qDsPvGEIkbW OrMFK/ZJqzDrTsMkGBBNU2oFCorSoNFO3XAWQColGNVBA5VB2I4+BP2siWQRKsQrGlSd6eAyLY5Q GB2rUVpiqjNUd68QPhyQYyQkiyMisRWnj2yQceQJDjxVizhmC7vSn0dcUnbcqYCtEChPw0ALDffs DkurXsY2Frsp+KvJSTTtStf44hjIjm//1Z763JvgZTEwHw08BSgH7OZPC6rjs7fS0ECkgDirEEg7 7Cvw9f2sNqIgbNFCAKhSo3Ab2OwX/WONoqmwaMrEiNhvQfZIriyvr9LiFDs42TqB7nwwMK9V/wAL bh3jC0BCEDiu1agdSP5cRsWcgSHU5BQRsgYcd+JB+zT+X4sKOa9DU8aV34h+m6jIlnE3sp3KKLau 1SyknKMp2cnDADkg+xzCc4ro6mgGIRaaWsPEV7nLIhiUYNssQ3ih2KW8VdirdcVdXFXYpdih2KHY pbxQ7tgV2FJdih2KuxS7FXYq7FLeKGsVb2wK4Yq3irsVdil2KuxQ7FXYq7FXAnFQqxvkSEqoNcCu IxVrFLsVdiq04VQN/wDYOWRa5IKwr+kl/wBVv1LkpckQV5RWVj7n9eSidmuQ3aGFQ6m+KpPrjH6/ oyilfrRIqARsm3X55lYBtL+q42oPL+snjEIGDAOaDcdx3/4HKgzka5rXZGNBQDZYxSnetaZINZot qP3ZBopAGwrsQKb/AOtg6sgNlyMFqAvQ/EK9jgLKLdGrxYUBoa/qxSiApJLL07eOxwMurq0c1HH3 r+rAqnMOYJU9BuR4YYsZboZFNQvIbnj71yZa4qSxsxkViFKqa8zXepwk8moAmwpj4EVl+yDX2/ji xGwtbI3JAoWpJBIXvvywhhM2Kp//1pr9XjWP1SpHKoCiu3geQzN4iTTo+ACPE3EOIViGbsORr1wF lDbdcVaipzIkNByHgD4YEnuXCVwopxkRjx+JaH/WH+TgpPiEf0l0rICyyclI+ztUbdqjEDuZyI6r lDO3I7DqKd/9WmA7LEEly1Zq14KTXiRWpH04lMdz/NXOG4Gm5Db/AE4BzSQaNfzlC6CiHiDSrio9 8x8zlacAWh8w3NKKtYt6kbYQGKZxrtlwCFXCrsVdiodireKuxV2Kt4q7FXYq7FW8UOxVrFW8UuxQ 7FLsVdXFXYq7FadirsUuxQ3XArq4q6uKurirq4q6uKHdcUt4q7FXVIOKqqPkSEqoNRgV2KtYpaOK tNsMKEDqAPGg9ssiwkgtNH+5JiDUcSPuphmdmEFdz+8b5nJjkg82hhQ2BitJLrNDq+hqehuHNPkm ZWD6J/1XHzVxRCemJTxdqbDfjXbf38cqBSY3uVtVbahJFQKmhpWu/wBGSY81xBLfDsr/AMciz5tA ujmgU0FCKUHhXCd2IsFVRaEBtq0HWooe2RbAFdaKzVB2rgStBKMxHXao8fnihSkRgCXB32GSBYkI VgRzCjsDyI7Hv88k0na6WuihSTtUA7d6GmNokBSkV5KxoKKenbf+XJBrIsKQBY0J+RrhaQLL/9ec qG9JuRIeoA8CBX4STmX1dMAeE967lGCjIfiG5XrQn/iWDdltsQ50Yu7H4mFPiIp78qYgrIGza0Ue prtSi9f2f+I4eTVzK7kKVU8VrWgFRUD/AC/i3wNl93J0cLoWMZ9PrTaooR9rj88TK+bOMCNwV9Zg WIKSCopy2/2Qpg2ZAnf6ZO9QboyFOfxECpBpt2xpBl0I+pRuRWGMk0PKpHyzGzubpPo35rIY+QHc 5iByymUKBQNsmAxRS5YhdirsUOxV2KW8VdirsVdireKuxV2KuxVvFWsVdirsVdireKuxV2Kh2KXY q7FDsVdirsUOxS7FXYq7FW8VdirsVdirYNOmBKqj5GlVAcCruuKrSMVWt0xVA39eJp1y2LAofTE/ 02ZgPhIqPap6YzYwbb7bfPLByYnm2MVcPfCqSayK63oi1ofVlII60CCuZmn/ALuf9Vw9R9cWQRiR KbclY8QCaVA98x20AhocQTxBUsKk9RhUKbMTsjbA9afqyTCz0XsWptsKUYVrsfngZlehBlA3r+1X psPte2BMTuiKqadgTsciycAKGu/c74pUJpOKsEFdyN/fuKZIBqlI0hXKkEDcgAVrQ7HuBk2qRCm7 B6GRt9tq06YhiSDzUmJK/u9+J6dqYWqRselwVixO3w9ugOJKIg2//9CfyCWNBStQ3OTbbl0H4Zki i6yVgLBRiTWqMPiFKEb7AdMPJhzK8Kw4o32a0pSpI8cizMTsCtf04/3fXrWg6Vwizuwnwx2aCqxq dlHUfLDaIgErlYbOa040BqSDQ4CGwHq2EZQWqCCRyHscbQIkbtNU0A5E9KHwriiSncUcRgDrU0zF zc3Yac7K0EVKGlMxwHIJRqCgyYYqoySt4q1ireKHYpdirsVbxUuxV2KuxVvFadirsVdirsVdil2K HYq7FXVxVvFXYEuwodirsVcMVdirsCurhV2BXYVdirsVbrgV2KthsVtVVsilUBwKuBrirRXviqXX 3f5ZaOTAtacFEs/HoCor/sa4JIj1Um+0fnloQXYWJdihJ9SY/wCINFCmhJn/AOIDbMvD/dz/AM1x M395BO+TMoVVJCbsoNd/nlLZa5FHJS32SaGg+4YpDS8aMaAMATSh3Na98So2aU80aopWvEDx/axQ DYaikDSgruTsRTY075I8mMDujN+Va0A6eGVtyyrEFjtv1wqozJWqUJUjbCCwlG9kKgdQ7ov2aAt4 5MuPG96U3hVmBNOJG4r3P7OEFhKFlSZinwnYV3C0/wBlhDVI1svcOy7oAVFT7L44AzkCRyf/0Z4v F3LOzP4gk5lF1MN9z6nCP4AxHEMdx3p22xJXh6q05K8T0IHSvhvx8cjFsynkpqGIZwpqaFh7HvXC WuIuy5h8TGnBQBtWv68VIon+FduFDg/FsKHt8jiz6W4iMIQtQtNztQ+1MG6dqXrGaiQmo7jfw6j/ AGWC+i8B5l0kVXQ+A77Zi5ebnYlaNcgA3FWUYUL8KHYq3il2KuxV2KHYpdipbxV2KuxV2KurireK uxWnUJ6YqtpLWgFcVS+61m0tpmhllVZU+0p6jBahQPmTTa09dcd16rW8zaaP+PhK+Fcd0r4PMFnK FIkU85BEvHf4iOf/ABHHdaTdTUV8cKG8VbxV2KuxV2KuxV1RirqjFXYq7FXYq7FXYq7FWxgVsHFK qGyK2vBwKGy4A3xVLLqRC1Cdj+rLgGBKrp6AQeoP92EsPlkCUgIYk1NMuDWWxvhQ49N8UJLfqX8y 6QoNOKzkbV6rxzLxH91P/NcTKLnFO05UZk2bpSvh1yosha8uSyuo2O/XcUHX/ZYGVtiWtKggqa1P TxxpkJO+GoJAIG9N9v8AOuK7FdxKyqOlDsKDcHG9lrdXUkDhtt0Na9e2RS1yYCtaEbbe+KqMzkja o2NWPTb5ZIBBKG+Cq0A8TWuFq2Upw9SgALluQbxHSmSDTMHktlUEfFx67N0NW/pTCFkO9TmdwwBN W4jkeVaqegphAaskjb//0p8ZGSijiG3qTuKf825k1bq+IhcqNI5Q1BIB26bb4LpIiSVswqqlRRan iDsabVdv9bJRYZBsFSMymqIvwKAWNdgD7ZE02xJ5BoqD9tiu/wBo7j+XFBHe0zuWIr8XIChFBQDE BEpG/wClxNqC78RSnUgd6dceSfqNNFCwI5UOwp/TG2JBIq0TIAsaE9KgV+eY0nYw5BUUZWGxeowq uxV2KuxVvFXYq7FXVxV2KuxV2Kt4q7FXYq7FXVxVeh3pgKqpBBDL1wKXk/mK8nutYu5gqqpcpx2/ Y/d/8a5ZEbMIpYJ5/FB8qYWbg9yf92IPnxwrbIfJ1nc3mq1eZSluhdlABry+FV6ZGXJbt6BGpVeJ HTIhV9cVbxQ7FLsUtYq3irsVaxV1Tih2+KXYq3XFDVcVbqMVdyxV3LFK4OPHBSG/WUd8aSh7m8VV JJ2GSAQSg4q3UoRRVTQs3gPDJS5NfMpuFCqFXZVFAMqZpZXeuXtR5rlOFQ388VSa9RpPM+lqgq3o z0HT+X4sy8X91L3xcbKLkKTuNVUkUPIE1WvYjKSmIpdTfmqha9RX/OmKaWMaOpNeEfTl7/24WHI/ 1V4p8BqPiOxpgbHKvOdQANtwSNycejGrKKCjrSgp+ORbFIyBeSE/F1+g9MNMQVBpFAWg5SE7gfP4 clTAyWOrglivFaEnpWo/YxCDfNRHJXRWHFt6gns3T/gTkmkbEWplHVfTJNGPU+3h/N8WG2HCapoq kRrOeLbcQN2O/hh58kUIn1P/0586oWD7lWBqfGu/2cyQXVSA5qyBkj47vTY0oK+2+RPNtjYFfUsY IUUkcjT4hy6f6uEc2MgKWeoyLVB12K9dx44aa/EI5LlUF6hviFCx7Up2wW2AbtuoekzUA6j3pTt9 OINbInG/U4Dh1HIg7AD7QJx5oGy8AF6UIY7gHqPlgbALKKaH1Lcxk7kUr7+OYx5udHkhIrkxN6Nw CHGwc9Gp+1gplaMWWMioYY0q71E/mGKtGSMftDFLvVj/AJsVt3qx+ONId6sfjirjNEOrUxpWvWi8 cVtv14vHAm2vrEXjhpbd9Yi8cC219ah8cUWGvrkXXGlsO+uRYaWw765H4Y0oK369EOx+7GkEhoaj HXYH7seFiJht9XRBVgafLERSZh4x5ie7TWb1QhCvM7oT4MeY/XmXCApqGRKRNef5gZZ4YQMjZnvK 9Pwx8MJ8VkHk/XbrSdTW5kXkkimN0B6gnbKsmIVszxzt6vHqTTLz9MgGhFSO+YvCz4gv+ut4YaXi aF63h+OAhQWzev7ffgUyW/XW8R9+Gk8Qd9ceu1N/fBRUSDRvXBptX54oMqa+uv3I+/Gl4nfXT/Nj SbDRvWpsR9+NMTNb9dk8R95xpPE764/ZgfEDCjiXLcSHv2PjjS8S363KAK7HwpivE76zL4/gcV4m jdTe/wBAOEUvE76xPUfaodx8J29jjsjiKokkx+0WB7fCcWVqCy3shNEelSKcePf/ACsJIY2SiYrG 8kY+oAkTChru33ZCwmkxtraG2j4RLQdz45Em0gKkhKozDt/HEc0oArl7BaQR0xYlwJwqk101PNWn CtB9XmLVFevQL/lZmY/7mX9aLi5DWSKf8uLM1a1p+A45j9Gwija31VCEU5Hqo8DhpFqYckFvir0+ nJNYNrnYiNSaepU79136YGZJpUQUYGvw9fpP/NOApAXpICfi6EgNXbb2wEMgd1J4kBZgeO+x8aYb LExC0glQ5HwV2Xx+nG2NXu19WleikVrUsfc/PDxL4ZPNSdCHBkZU4ACp3Y07cd8ILVIUbKnLcqyt 9XAjX+Yj4vo/lyQj3tc8oI9PpQnqHmWapYihY7mtMnTi8e9l/9SbmW4Ugc0YsegXYCnzpmZQdLxS XLJeksGk4oNwFApWnXARFkDNaWmYvWcsw6PQBRT7S8R9rDQ7kGR6lpri5iC0VJ0UbdiSev8Aq4RE H+ijxDH+m3FfSgE/Vz8RoByHXAcY72Uc1dFzXp5DmjR03oN9+vX3wDGiWYk/zVRJ4RVi/pk9OQbf lgMSyE49/CretEF2PNgP2f7ffIcJbvEAH85G2784gTse4zHmKLnQlYantop1o4qex8MiCyItBSaZ N0hcU8Dsfww8TAxKkdOvwfh4n5sf6YeJeErTp1/WtAfYsMeJHCW2069CmgUbd27/AEDHiUxNKFrH eNzt+ILqR8ZJp/scJIREGqRo0+7oK8PepP4ZHiZcJWy6TcOyMZForV3qcImnhKuNNuKli6CvgD/X I8S8K79Gyd5V+gHHiTw7O/RZO5lrTwGPEjhb/Rh/36R9GNppw0z/AIuP3DBbHgb/AEao6y7fIDG2 XC2NNjOxkantTG14F31CKlPVf7xjZUQ2WLpsVatI5HhyGG14GxpttyqZH+QfbBaPDDn0yzYUZ2p/ r0x4ikwDDfPmgWkdmmoWzH1Y2CygvyJRtlah/lbL8M96ap4wHnj1rUdMzA0EepoP19sSEEhwLBgy 9eoxITdbvW/LF5oVxpNtJLPFHclAsqPJRuY6/CxzAmJAudwiW6eQw6VKSsTRu47BwT+vK7LHgCt9 QtOnpg/PASy4Q2bC0rX0V/HBbHhBXCytB/upfuxtNNi0twdol9tsbTwtGztlYkxJU+2Nppf9VtgO XpqB/qjG0U4W8DDaNaf6oxtad6MINOC/cMV4W/Si7IPuGNpAb9OMfsj7sbUh3BP5RjaKb4L/AC42 mmuKeAxtFO4J4Y2rYAHTFWzirWKW8CHYVU5nHH0x1O7HJxCCVDhk0NFMULSmK0k0sKy+aYTUAwWb N8RpRnccP+ItmXA1i/rTcLIP3n+anLszKo6NQggdDXp0yumZJIWEj4WqaqSCO2Fj1tfwRFbiAGO5 Ar36Uwc2XCAuULx5Gjuw7VqCN+mKQ6q1Bq1CASR16f1wJttIS1W+2SftYmSgNukYTk7CM17kYglZ VW6m1wiJ+5/eciAT+GwwiPexM9tkFcSzsSzSGg2FD08Kj+XLIgOLklLnaiXZaN/uzxHjWuSppMiP 6zo1kMw9MFq/aT37g4mqWIPFs0IgatTjQksnhToF/axtIhe7/9WdEUA3UEGhRfCmZbpzsGnlPqMy fD8JoOu1ONMIGzGWQ3Ya4gRgN0NACdzXxoP2cQd1I23Wsp9L4SOVTsBvthHNgRsvVX+AU5D27VwE sgDs06c0PKhG54k77bb4g0pFhaYQKKGNevUMB/LQYeJBirRvd27VCoQ3X9ZORIjJtiZw6I22uIid jx5bhD1+f+rlGSBc3DkBRmY7lNjFW6YFdiruII36Yq0I0U1CgfLFV+2KuIGKuxS7FLsWJdXFVC7O 6DtSv44hUOEJNVb6DXCkoS8gnpzHLbuu4+nJBgbYj5o1C6tLeh5hCaB1LAmh8K5OAtFsMbzDck/B HcMT0Jd8u4B3s90fp97q9yy+nbzsa9FLsdv9XKJmA5lkASyXzAdYh0+yDtJMrRksiI68KU+CVv58 rhkgSkgsKu9ZVX43cMygbct2G2ZcYg/SWBgSpJqOlXDARy8GY0UEHrkqkGswBR0Vg7EFyrD+YZOJ JceUKZhpvkaxu7SK4+sswkG6gDY/tL1wTy0apIx2HTeQ7US/u5WC0HxGn4nEZBXJqJnE0oyeUJoY /rGn3bCZGCiNxxr7h0P/ABrgIB2bIZjVsj8uaprMU/6M1qI89xBdqeSvTqjMP+FzGnjFWHJGQHbq ygHKGwOxVwO4+eKXOdpKU67/AH4hXE/u2+gYob/ZanTuPGuKXUoaV7Yq6tNsVdih2K27FLsVdgQ7 Cl1cUU6uKuJAFa7DvitKLXK9IzU9zkxFjalyr1ybFcG7YFXAg4q40oSaAdye2IQSlUMHOW5vHUVn I4KT+xH8KcV+nm2Zd0AP5rgn1Wa+pE8dqISAAOnWpwWmtqCJo0cZEzqEbZeQ6n/Y75Dm21Q3Kl9Y jVlpCQw2BLUB36ZLh82Bn5NGdFZuKldyeQIP0YeFHiAdHfW1oUWNuRG3Icd61748K+L0oqhaYg1N QtKoNhU9sjs2bqSAVBYVFe/9mSLABzkAsF34EnbYjeo64ApKEZmOxABYBSD4DvljiEnl/OWBlYP1 JFKBRhYgg2tEhQEqWoR0Boa+ONWgSpSWZ1+MV4gkAnxyRDATI3f/1pyqhWYuwqTQAU2HfMsl0/CA 5kPMBTRq049iD/lYgoMd1OQMSFY70qd+498kGuXPdVYISCCS3Thv99ciGUgF0XIAhSeR7qabrvvT EsoX0c6h3CiiqorUdx1wDkymLlX8K5eDLzApJ0rtTf8A1cSyjRF/xLvTJWtQaEgdxt7YLZGNhTMY eitUOWFH8APsqP5Vw2wAv3ou3uyn7uU1K7Fvl75VPH1Dk484HpkixcRFeVRTx7ZQYFyxMUuEqdAw wcJTYWSXlrFT1ZkjrsvIhan/AGWPCVtY+p2EYDPcxqp2BJFCcFMqWjWNMJIFyhp136fPbAtLk1Ow kbjHOjsOqqanFaXi+tuYTlVj0FD/AExWmxeWpuJbYSj14VLyoeqqP2jimktPm7y4DT6/HUdev9MP CVpoecPLh2F6p+QY/wAMB2XhVf8AEmj8OZnoh/aKMB+K5DjDPwip/p3SLtwILuMkClCafryYY8BR SUIqDUdjiGJWu1HAOxPfJhrJ3Yl53vFj9KyaJXMi+p6h7UNMPLdlGO7FdItkudVtbaQfupZFV1HU gnffKMs6iS5MRZeq2Gi2NgaWatGD25E5p5GUjuWy9qTGZXlUI7mngopk5ylLYlrFBiHnHypYtpd3 qPJvWiUMFoKEkhd/vzL085QI39KylbyqSwRX5qg5gbU2zcRytEobbJ75JRNV1Cay1BiqRRloynUs CNjmUdhYcGRPIlntppVpZzD0ZJkYE1USEVB6fB0+1lZNjlFoGUg1aYM9X+KvAcVLHr0PX55Dh2Uz s7/S0kLolQeJJqa0xJZx2Cm0k6ziRY1pTiDyHQn2wiIIpr8Sp2mkN/My/vYfSI7Hc7bVzGOLzc+G a+aF1bXf0dp814UDiKlFJoDUhev04PDbIzBNMWf80lQVNmtOxDsf4ZHwyXI4Qo/8rXD7rYcq9fiN P1YnGQvCFUfmfMxAFgvxH+c/0yPCWJpPLbzd60fN41U0DFa+PzzGlkILASCbaJrMOpLIQjLwHLem 4+jJxnZotko0Ep1Pzpa2dwYQr8h1+EEAffkQZS5MhAdVWLzOJ7T6xC6GoNFagatdvgrXInJIGqZD ECUqufOWpRcl/dI6tTi6N1H7Jo3w5aJWylhDtQ83ajbsoilgaqoxqKbsoZup8TghIlBxALLHznqs 8U7Oqsy8ViEcdRyZuPxUb/hcnI0WJiALZAL3U2IURzrVSxLRRjuKbepkeJptqG61N3Yu8gSnwho4 xv8A7FsHiKSFqXOtNJThLwABqoiFd/8AKbJcfkxEl732rjkBp87AGgfnGK/5X2sPEvEgdY1IWV5a rP8AWIlnjDNG9Go3RqcD9r/fmXwjYRJWt7lJKm0mWShqYwaMP9ZW3GTMSObTGkTHfkbSrQjqR0GC l465ouKVXHJTgIZg2vDY0m3SqrpxZwqk0Kk0r7ZKIaslHYthVR+XIUBoCTsDSlf9XJsCAC4PGpb0 qFzvyOwB6/DjRRYHJQepkLyOSjEADueJ+Lpkxyajd7ltipV91J6qnfev/EcWROy0RCp/ygOvTpiS gQcFLMDxLEmoPjx/lONoARK8gxHTuPcE5BuHNRCvR1XerEcu1Oo4++Sa6KyR6lg4HLkASfDCESPe hmXkFelQa0HsMnbjyjdFTQEgkAgr1Kn9n+zCWuI7mlITlGafEKEsK9fDFETWzXLgnGlVCkH32x5o JoU//9ecKGDAkEb9fY5mOliKO7byMI68abbHqT3XABuspbKXFQdjuu3jvk7aiN1eOQxpRaHkDVju D2yBFlvjLhCqij0gjbAgj33/AOasiebbEemipUp+6UcAdqgbnJebRe/CuovNqCnEV36V6YGe1lwZ FJFAQfiIG7bfzPimJAK5CoKsRyVlJAHXicBZciFrGu+wp2r2Ipvha5d65ZFWNggbnTY12p+ztgIZ RnQofUqpJLz+IfEevtkSBTbCcr3Y/wCaILu5urH6vBLJEkrGR4tyooOp/ZyQHpLZjyesn+FKr7Wt IsZI4bpZoZIuLEzSljTr9gKcxjhl0cjxYyQ1v5t0QiRIkcqxoGEkgZvnxC4DhkN24FF3GqWnMTQh khkGz+pIH2G/7YyAEkoey12xW/iFzcSfV1dXcq8jP8B5UC8mPZcmYSprid0w08Pf6lqMunwsLe4S UQSSOFDKw9PifU5c9/i44zBof0W3jADENW8tarpMnrzr6FtK3GF5FBJAHT4WI5ZdxghiCVXRXb6w KalbwEEU9WJyp/1qZjZREhtjxA2zya41trKFH1rRpBIoeJHVoVaNj8DK3qud/wDUzH8GJ2/hi2XR 5S4mI6jZ6jK7O8di5VuLNazBq/ysqua5dCo7epjKRKL8px622pxQrI9rasWMjMwdAF/yHP8ANlkg Ka7eofo6L0xzlJam77AH6BiwYJ550a+muIbi1HrpFGVdVIJG5blT+X4sAITHZiGnz3NjfRXUZX1Y G5Kj1Kk0P2qUODJASjTdCQvdmQ/MNzw5aeikD4ykpqW/yFKLmCdLvtUWw8I6yVh+YqkbWLAio3kH 9Ml+Xl/RQIxPVA6/52Oq6dPp8dkIEmCgzGQs2xDfYCJ+0v8ANmRHFuDUWBiB14mFvE1CTQ7djmQA 12nXlV9F0iV7+bUI/rM6FPR7rv0NBmcLMaddmG+zKD5r8vG5Dm8jormpKsR06Hb4lwcBpo4DxW6b zZofKWl5yrxAohpQdAPlVsAhyTO9158xaEzhzfAE8ahUY07cm2xohfCMjdrj5o8srFtdkgdV4NVl qfb2yNSts8OIFJdc+cZCrR6VZzXHOv71uwPguQM4R+osxiNbJLqmoeZdXsZrGWxMUMiruiHkSrVX fK5arFHcFuhhkEnPljUzbAG1lPEAGqmuYh1sAbtzhE9ViaRqVuvE2cigdyjf0yH5yB5lPArpHPzU PGQB1BUg4RqId7HgtklraytBygVSKdCd8xjmjfNpOIxkybyfLW1nA4hkjO1d+mWx2kf6rfOJoMN8 xW0x1KX1SVcsaDYCnVfn1y7HyWQUXsvQit3nfgvESKy/a+Jv2qH9lceO7AZwjSQalcXjSO68pfUY tyJoTv8AET/lZfCMerUZEFBm5uSBz5EHb4uoAyzgAbIysJ35c1a6tbuOKAyvDM6yXEUKhpCIazKU 57Lx48pP8jKJ475spVSYWn5heY7ocluYloxLAwJt1+FsnLCA4nVSl89+bY1cprFuTH/eKtogIB6V qMRjHcqrYfmB5hkmT61rXCIkcuNnG1PnTjk5YtuSdkVq/njzBbvzt9YSS1cDiRbIv/EgzZGGO9ix LH5vN+qX11DLeXUdzNDRYhT0gV68W4L/ADZkxx1yYSlYpl1trWnXwjW/h+rXBFfVjbofEOvxf8Fj xVycbwyEyWXU4U52s6albA0Ec20n+xmX/jbGon+ikzpRj8y2ENwkF2k+mSsaAzryj5fyiRSf+GyX gk8uGbDxAP6LJ+StCsiyqykBjxINRt9jjXKgN2U5WOaxowd2oyjZmPU+/tlgLTKPeq+nGdgp3FCQ Pu65G2zhC6KLcBx8Q6gGgqOhxKwj3ryVqxCVZTuw99sDKxawU5AkUApRe9T+y2FDmZfVoKKPbuf5 cCSd3RBgoPWhqTToRiWMBsruTUuRRTQCvgPiwBsKkdozT4Sew/Vix6KF2g/d1NWoS3zOTgWnNHkp REFhGRUdB2FckWuBF0pj4aK2w5HkV/VhYDbYqdQzMKU5Gv04WHMlYoDPwZgy12pthLXEWaf/0J4X jkXarHoQRTr/AC5lUQ6kyjILCFCIAKcuTH/V6DCwIGwXAGL7IUggb9dz8seaSOHk2P3rFioApVuP SnQY8kfUXShjKNx3Fa7VXp0wR5JmPU2QaeqN2JFR238cfJa24m9qNyHXjxUD9r5/y4sq5tBqA9ga VHWtdsaYg03HQtxJ+yR8Rr0/5pxLOG66RuJlVacTTceGALM1YbUKHod9grU8TiUxABVFqDv0B3HU /wDXWRLYFgYx/DTiGoWJNCaDvTJEW1g8Ozzrzrc2J1OSL6iHukaJnmdyQUCh+CIF/a5ZK9nIwYrF r/JPliHV4r65mleH0pEWIQ0p8QZ22avT4cx8s6oBzeGmUHyfchGj/TNw8Z2VJArBR4IP2cpM/KKp NP8Al8kcxdL9xI32WaNW/Vh/MdKYxhunnlzToNOQxLEqz8P3si1o5r/KTxyyM+INOWwUh1BheeY7 yK5UNbQNxgirVAQAGbh9nkcxtVIxiKczSxBRy2lqqhFiRVr4DNWZk9XYcIQesaXpyWzMtvGWMkY6 bUo7cafy7ZbgyS72EtyLSea1tVWqxgUrxoKUHbpmVGZtGTHGkVoXmmw0W9dLqz+shlUIF4Ch/b/v fhzLhAyFuHwjv4WUzfmhoRiPLT7l0A3UiEDwp8UoyfhsjjA34opFeed9Dv0cWmjxrKVCRvJwanzV Ph/4fInGQ1JTp5ubi8Vre3g5ipWNwAlP9XIyoDdQik1V9PaSCSxt5HJKuevz4tkeC97SERF5n05B R9HgYgDYU3of2tsfDPevF3JbqeqxXgX0LKG0VQQPS60Y1+KuTjGkWlMpnIpyBHhTLAAwOzoprmMD jSgpsFH9MktIaTVWVgChJQkAkDud8tGMlgZAJhp073twsC/DLIRvg8EsTljTPLTy76MSi6SKcL1J MgO/sKZV4YPUuPLMQLpdP5ZgMQMSryViSFLMSD9lfjPH4cjKHm2Y8nU+pQFbZWQx8Qo6fZ/4IZr5 Yd93YDLE8lOC/knDKj0avUmlO3wrkpYADyRCZKX38moRScTdsle4J2H82VnFA9G0SJKQTeZtTt1M gvpGANKBia++MdDEnk2Aq1r501aSMMbnmK7K6qf+JDI5OzR/VRxAJzZavqF/8LWttcr1YOqg5hz0 vB1Zx4ZMs8vaSgZ5xYw2xkiMTtGxYFT1Xj0yOPHkJNH0olIRHP8AiY7rXlzQo7h45HuYJWoWZKOD 4HicnHLmiGwY5T9QSi58tKSGtdbCNSgW4HE07J+0MshrJjnFjLHIdEM3lnzEKFBDeQgU5wurNTx4 /Dlw1seo4WoxR9x5Xt4PLtzqc7ypdwugFuygVDME6fby3HqhI89kyAA2SPQ9WsrHUhNcfu0VJV5E UoXjeNf+GbMqxIbHice7Su1v7ZUFdn/azMMCWpOrGOGeAuEDAmtcxpEgsiERDa2xlPNe2wUA75Ey KF2pRKsNmpQVMTEgin+7ZPH5ZZBCWNBAd/TFe22WWWJAVfVVJPT6cewwUqvDqs8LK0MrJx2FOn05 ZdMZRB5ptF5ridTFqcAnibYkbj/gDhjI9GmWnB5JrpElkGM+h3YQEDnZv/dn2WN/ji/55ZacnFtI ON4coHZlWnTiWMq6ESDaUHpX/Jb+XKZimzEQdkdxVEPIUp1/2ORbqCx5lYNx+KgAFe9RhAYmY6Ka qw+0D8ZB5En/AGS7eGEsAC0ASrF+pNAOxp+1ioF81xiIZFK03FaU64LSY8laNDF1FfHuK5Em2cRS 4qWBTcctl36UHLFJUYipqnGpG4r1/wA+WEsIm0PcMGkag7kV7UGTi1ZDZQ+wDOVqSKKQeh7ZJxxt Zpb6zcfTI6NU/Thpj4hqlJSODPv1p4YWETsStWhJXbkajfqB44WIf//RnRR46fFVvtGnWv8AlUzK u3TcJiukd6nluAK0xATORvdaHIjp3kNSvao2U5KmIlt/WX8iiVNQzAgP3H+rkaZ2QGgBu8a8SgqC exO1ThRXUKgoqHk5Eew9tt/+GbI9WY2jufS05A4qT8NSelSBTamIQT0bjaIFVkJ4Enc7n6KYkFMS ORWRwnmvI0O1FP8AT6MJkxjDfdWiTkSrCnMnjkSWyI7/AOJcYoyaIaGtWp/KPtUwAszAdFNFAHIG nI7qem/TJEtUBQt1QQQRyIB+HsO1MV2LzvzhpmoNrE92sTNbzFfTcCvRFUg8fs7jLBGw5OHMBsif J+vpoUM9rdW0tZ3EqOig1ovDvmPlwkuSMwOzKT5x0gxqwY8yK8CjAj8Mp8GXcyMgEv1LzRaXCxxQ LMJCxqzIUWhH2eZ/5pw/lpVuxjlF7Kukvf8A1kn0+cLAcpARQHJ4sYiN2rUT6BIonMmu6k/Wsr/8 SIzD1nIOx0ZFI6NzRSDSrbHMAuxKlqkzPpyMx3ada/JYz/XJ4hu0TG4SiRqrXLxzSSxTU5SdY4qK kgbZtdOP3brM28mpJSUIbYVywDdrBrmmWnW0jpWPcAVyiZotgRo+sW4MgIG32h2yFAqgZJ7hjyNT UdT75bQY2pGS4pUYQAiSxZbg9MNBMeTZa46UO/iKYNlT7y0WnuUtJ9Oju+ZHF6lZPf4uSpT/ACcE iB1RIEs0fTvICp6s9jb25NRIZXK8XGzArz6hsmDkHJxTGBPJ2jQ+Q7q9/wBxL2rXUbEIg51qP5ee TkcgG6BhiyF0j4qHkRO5ap6eGVBZ1W5WIqgVWRNulG6/RhLCNDkQpT2yOoeYB1aoJFOQO2DnspJG 5QVxo1qsYkicxClD0Z6nvyp9jI8IJbTlMd7Y55ggNrA0UsqVlRinIfERTKzgF2G3HnlI7vOLqEG3 ZxItBIq8QQKkrlosGnYxlaHhQqfhYA+5GSKkDqyTQo53jMgmVSCf2gO1PHNfqNjyTAgFn3k67uoL S/ea6iZI4yUVpQSGFN+u2UcBHL+a2SMZRG38aTXuprdXMdJlJookLOCef7R+/AcVWW+GQRlQ+lKN dBVwsbAqRUsCDksUL5pz5LQljKYFNSSxB4kMRQ9m2xngB5ho8QJzBqepwWDzhpZV5COrUkTk384b MSWmjbPjFKb31hdqBqelwzsBvIqiNqf886ZAY5x+mTRKAKWzeWfK99X6lcz6fMekcgEkfy5AckzM hqs0efri1eGCKCYaf5a1myt3T69CLBUaRpwSykrTiOMa+otctGrhM7jhmwlApTJfukrok6vQ8ecZ qpNeO2Z4hYtpMui97m+uliEpeRYSY4qjoCeVF/yeZwgAMLKr6FxE1LiF4wuzclIIJFRXCKW0A+mX l1fSyQKwWgNe3HpyOS4gAnhKrHoV6aty5U/yuQ+7E5AkRK6XQL1dmYKaV606/LB4gZckHJot9GS6 3PpsNxRiG+jJjMO5qMDb0D8vpdYmW4S/meeDgBDK/UsCPhZj9rISmL2YnHQtmwQ/DyPXYn5HBaHC Fd2b4SCSPnjbHgDm5BRT7W+9Nz44hBC2NnbrSla7fx+7CVjZVlSjE1DEHYKO4/ayJLNtwaso3PcH 78CqcjCpBPwxjr7nCGJLUj+iglbZiKLTpT9rCBezGcuEWhGl4qeIDFTuw7/51ywBoM9kPG1EMbGi fa7fs5ItEDtRaHNm5UX426jp44lABJv+dJbO1QOFQvVttuXfDFGWW2ytDGFTmtGfelRXqMhI7t2O IAsc3//Snig+mxjBFTRvCo/ZzK67uoH07LTWhVqioNO9QThY1tuucyABQtAtafLEUiVuUu6AgEla EV3oOlMB2TEkh0jCQgsAZF60qNvfCBSzlf8AWVKBI0DCpqWIp1r0pkeZbDsA0qDi1DUsenffCSxj HYrF3dFbZlO/cYTyYA+oBWdwEDDY0O3cGtMgA3SltaxRIqsWao/ZB6mprtkjTEWOa+hVGdSAXqq7 1IGBnVAn+cuIAXgBVqVr4UwJIoU0lShHDcrQMehYdKYSwjuOTnVZGHwg1O69vng5JIsoKbSLC6+3 b0bo7KSK+3XJ8ZHVEQf6q3/DmmFWjCNxIqCGO3tj4sm2r2tfb6JpwlA9GoAoWqSf+GxlklTCEPVS Zxw/ZiQBVqOApSgr0plTfwmqeexBRrGocejzSH6C7kZg68cnZaI+lXUErEK1NQRmAS7EyWaoQsEC DesrEj/VULksO5LAmylFecVelTmR1Y9EmEAbVpHalAtBmfCXopwZhVu7GJrN3CguOvyyUJG2qUV3 lS6Jvlt5D8AIqe9DtTDninHu9X0Xy1ZlJZpYw8cgKrG4qOJ75hglnySfUfLNotx/okKxx0OxNR+O PiEMALKWyaC6/ZRK0+LwBw+KkhSOgSoakJT2yQypEUHdWqwyBOHKngMmJLS2C7nsn9eHirDfp0oP 7cbtDFbuVpy3rHm7NWjbjc9aHMoEjkwMQWR+StPjt9ZsCgKmVeVa9a8xv/wGPiE3bCcNnqpt41pQ 1pUAHoSPng4nGOMKn1SFWoyAilQO2+R4ikY49yncQxoBw2YD+3DEsZwHRKdV1f6jY3V0ycZIoXkR wARVVPBSP9bLY47aBm33G7wHV/MGr6jdNNeXTyyAcRvQAb/CoHzzIAAHJzoDZKWlkbqx+/wyLaNm uTfzH78U2vSSQDZ2A8ASMlWzEleDK1eRJqaknc/57Y8Ma5L4hApxaQGtTXxqa4BEIEy08lwNy7dP 5jiIR7mXiE9XC8u1pSZ9unxHIcA7mXEUZBq2rBPTS6k4MQxXkaVX2w+BA9EHMQzFZr/TtKsr28rJ He8hG3clKc/15rJYRKRA/gcmGTZNLeC0uFDK59Q78aZVKHkgnuRqTXekyx3FvJxLL0rWtP51/lyH hCSePZht45l1iS44iMzytI6IKICx/ZT55tIbQpxpc3rPkzTLS7topnUHiOp3qwNDmvldtvRkmt28 D2vpNQkg7GhqaYSaYkWxmwtrYXDmoZ4o+JHb4j9jj+1lRJZUjkjsVP7kRoe6UGAyKkOeCGRAHZGU +Cg/jkeMsCCgr3R7CVP3l0ARsIytPh+fz+HCJkKeS7yze8JmsFH7iKpDgbdcy8QPMtU58gyZnDSA DodqjLqa7XK4qQ4r2JrivVxArsfiBG9N9vtYq5IypJr1BJHemJKAKVKhRUGnHbYdcDJaqsTXqx3x QsZVo9duO9e/0YQpQl5dOkYTYllI8acsthGy4ufJwilNODQxlgff5HwxPNgKMRaynEqpUNvXj7Up hY1VbNqgIA47dBTsa4CUiNrjbmP4Cakg1B7V8ceK2XhVstipGeBUDajMcJ3Yx9Jqn//Tn54qpA6K K0Pc/LMh1mwCxUQyFozsoAoetP8AJyRJrdgAL2VCeRao3+0D7AZEM5b2sR3XrsR+onb/AIHJENUZ ELWozEsNgPj27YQxO53XEjkQQaGgFQR06YpPOlyzekPlXpg4bSMnCsiFJOX2GA5A7k4SdmEI+q/p VTUkkigG/uQdsi3ktkoQeJ+EVqfYfZGBNgjZwX4I96mQ7/IYWIGw/pokKq1jVPm1dyp+e2QtyAK2 WiL0SxahUdBvUE/Zw3bEQ4WgjRgu5G1KU6480gcO5WkH4SFHNqt4jrTt3wsK8mhGVqFY0O/T9eNo 4K5LzGSeYbegAoKV3wW2mO9oi3Deopk3Naj2pkS2Rvq8rXUrWPVLoSyiORmY706kk5j6vGZOdoyB EWj4ryzk9ELKtR13HXNXOJFuygQULq97AHSJZAWiZyyn9moH7XfLMAaZmigVlT0E6dKkZkcO7Xxb JSKC9aVzRO+ZsfpcWUrRZPOMqgPBhv8ALAhL9KWS11gMFIRiN6bUGXTNxRi2L3i0vENnHDCCz8Af oPc5gcQ5Mpc2OavqHB+Fd+48MrjuWIISj9IyCJyzEVPUnLOFm39bb0xJvuNzh4WQQU0nqKsn7R2K 9xx+H/hskGKCvWU27kjiw2pk4hiWLFVL8iBXxOZN7IZz5cgaG50e7C0Bi47kmprKWp/k0yGPcyDT mNAFmzXUjLvXl2r75cIuvllNea6KZgvI7g0+0e564kJhkNWtIlfk5NNjy3rsMdkESO6U+dEWDyrq 8xoHaLjQf5TKvf5445HiDb4YFk83zrOKOT41/XmWXKhyUsrZuwhVaFKnfplnRrkUXFayN408ciS1 8Sm8LjkdyB1wsrUpXBiAHXvgZAbofB1bETbkhtu3TLaaZvSL1lv/ACJp6kVOn3JjqOqrNVxT/gc1 huOQt8OSL0i4jhpLGvKXjReZooA+19OUTFtsUFqt4/qcgCVY7V3IqemSiFSq5tJppUeIhWqCxbwy +MhTXIbvU/Jt/YaZpB9WVTOxLemSAa9KDMSXNs57Ldc143I4xsK12KnochzKapj9leTw3bAAEyEt XswHfJSApJ5oy4nvboMVYFg9NhQkfPK9gq4aZqqoDy+ChIRieVaeGIyRQo3UGofCGBJBqAOlR/Lk hKLWZpj5YgkS8k9Q0HX5nwzIxnm1ZKNMxSIbD9rufCm+2WEtYC9npQ7AD+bfAyJcENWNNidvYe+L Fd1oSadB79sVUnD1Pep6nrt/k4Qq5qitT8TbVGBJUWNR8QJ4bBO5/Z/jkmBQ8qRyBiE3JAQ96A5M GmicRIcl5gjJAX4ihBIagIAoG6dcFpGMFe0TP8QG67eNP864LbTG1sSBWAYFlJAIPjviSxjGm6qO Rfr0UDf/AILAy2QssfAkb1IDCnj4f6uWAuLkjT//1J3GrRqzM1QO/v4ZlHd1ERwg20j8pWO3I/Gw rt8hhI2RGdytcWqwLCqdd+nywUplZ/ormkA5UAoR9ilR9+IDIyXc434kruT8Sbiv+s2CqTxA03UO 5Yj+gA2GPIKDZWMUHFmUbn4uLE/7E18cIYyMeZC48eVd+O1DTt9OKaFt+k8ivKo2qEPc0+nBdbJ4 Cbk6MxGgapY7ED4RQYTaIkKrBF4kbbGgrWjHqci27BdzOxA+KnxfQRkaZ8XVVZmZG6k8t+/QYspG 1OaRgpCrUnqP7MMQxyzIGwajJNKDi4Gy9Aa4lYnZUEXxEE1Y0HWm/wDxtgtkILisiKORFBWlOwB7 fTgCdwx3zneX9loJkspmiuJplQPH9rjRuQVssgLKI7c3lcMA9b1L6QCcnk/IfESf9bKcpPR2WIxr Zn/lmHRygDTW7u2/xyRqR/sc0meM5Gg5gkANk01jT9KuY6w+g7odws8R2/aG5+1kYwyRPl/p0RyD r/uXn1/aR/W3WGvFakAGu3zX4ds2eO63ceZAJpBvCeJFDWuZIcchGiMlFUEBthTI2hF2dgrSqZGo lfiOQlKggyZauvxWFv6ERLsBQNXtmLGEiiyUjmupbiV5h9kjYE1pTLhCtkDYoSVyVBY7VocsDba+ khjA5U5fZHjhtQsAVfi5kHthUoS+Y+gxaQucMealj7E0rXbLwinpflyzcafpFw8pYOSY1B+wgSTl 9+VYz6pNGoHppPjOwUAHbqF69emZfC6k5dqVoUZtogWPUsd9vHBIs8cSdgu5qAI4zt0Mnj88i28Q 5D/Tsf8AzGnp5QvgCvJvRQ0O/wDeIcnhHqbJEGngNyfjI8MyJOTj5KOQbFyEBwT0rvhCDyTq1TT5 YyBX1D0yuXFbjkM50vyde3Whm+jiDIoJJ8QN+Qykz9TMx2YTqEDQyyKBVe4HjmVA2x3SSRSD7ZMh uiVlNxkK3ZI+2j5NQCm3XLTs4syy25aVNDVVYjk6U8Cad8wJfW5WPlad2SRLAUmqOQXcHoO9P5sx TbcELqFnISZEflCPsL3yUSxaRAUXlsab4VRNpIyUYklBtTxwSCQ1JNDAxcvxY7gVrkatUdYSw/WI 53P7wrWJe1D1rlcommQT6wvYpJmVBwIc9e9RmNOJCbTWRlefaTkoA5ISBkCxKCu+LIzE8QPsAdV+ eGJaZIvy4AZnTYkbUPU98zcbWyXjQbg1ruAR8svQ12AP2ehB264rTa8qkbEbioHj/tYobkChQWPE L1JpiFtQ9WEMOrk7EdBXJUx4w5pVVviQ7VrTfrjSTJajRSsGDUfcmu1dqD4cJFMQQVrkjlG3xEgb dq4hZdzcMTAtXdl2I+W53xkUQiWg55EDagp88aW91kz/ALxSrkstDxHTken04hhOW/NoMzyAk0YH r2w1SQbLTsahWLVJ2YdxXEIkehf/1Zy/qg8RuehHt75mCnSni5LgOC1X4WO5I8Bg5ryGy8pUqqbp 9puRoPfBbPg7vpbUKx+GvEUAPv44GQo8lqhS1CTwJ5Ak9Mkw2J/or2IWQgkEg7caHYj/AIbI1syJ ot+INT7HqRin3u5cmCMeK9BXwOKeKzS4R/tkihruNvbBaRHq2kaBVqQCT9ptxTElIgAGikbO1WoR 1YdMLCgSVRHY8jQMTtt4ZEtsSVxDUDcSUBO46f8AXWKSuFCSDQigFe4wMw5fhFUO5+ye9cV5DZVJ U0ZSPEt36/tZFmtRajkwG/Ymldu2FAFrZYUkCmYq25NCNlNOuIPciUe94z+YNvOfMc4MRcAgxgU+ yemXcUQNy3YRSn5ZVoL629S0XaWP++IVKch/eO/Lin8+YObLHo5mO0w1m90adr5prQLeTS8oZo0V lVKnYSx8fh/lbjkMYumUyaW6feWsOk3EQVJnkjYJKHIkjaoI/wBZdstlHdx7Q9uQ61r8R64TsjdE cEJq27KCa5EFW1lZQDUhe9cKAG3k2BXcnviGVKiSHjyban45EqvLVShFa74hQsq4G528Mkkc2+SM hPVsVQF4oEJ36itPDLYxYmQSYMeBNRsO/TbLK3Tb1PRmihttLj9NqmIyNxNasI+Pw+C/F8WU4Rcp NGpNAJqqjnVtjX7OZrpYjfdXLGOqREgn7fHYU/lyNXzbieHaLojUAvUE9KfxwFOPluk/niyN15Zv IkBqPTlodj8LV/4jjjlRbzGngd8lGrxpXeuZVOTjlaEyJbmshaqttcyW8gkjpUeIrh5sTG2Y2f5p +YrPTW02Fl+rEFdwKgHYhWp8OR8CN2npSRrrsc1z6t5GWjJq6Ie3+ThMe5gYr9a1DQbkL+jbaWEj 7XrMGJ/4DDjEhzKeFKLeNZJVDnitcsPesjQZLpemxXDqqGvbKpzIaYx4mX+bdBGkabpNjI4NxduZ HVTWgXj8JzDieImTlRHDshpopobgrKOPAAiPqRUVGQDMoW5vXkfjK7OFFBXsMkIoterJwD+1BjSV yuVcSDde47YChxTm3LgGB74qjIKLGFXdww4+2RISCmcMtLoOW+IMCSAAGJ26DKZCwpmE5WXq7KBI W3NBsBmMQx475KpkWRXCnnyrtSnXI01Eo/SR/pNF2NfjCmhoBmdh5FrN2E6owlrGxIFSa9v5sv6I 6rjI4A2HXuCTv440kkrW5EAOzGm4ANACPbCgtpBCV+EAu1AGb/hsbQIBcahKBa8jStfDAzIUqM7O zMEGwauSa+qm8Cvw4jc1r4bdMPExljtZ6M0bbSUJG4IrSn/NWGwWPBIHmvE00chJpIH79D/rYKBS JSB/nN1jdgyNQ1NFbrSm2BlsTYK0NQAcSf2mAPcfCBthY2pIJRxC7lgQy998ls1jiFLl4Kav8VKq tASSae32cCRXX1P/1ugRxinLlVzWvGtfi/ysySXWxj/plrLSJlJ4rUAE9ScI5tRFAjo2vxsYqfFT evh70xIrdI3PC4qByQ9uuNo4ei70aqOLjiV2rsWJP2cFp4NtiuhQMgLbE7io3HagwEtmMWN1jM7U oeVAVJ9jv+vJBqlZXR9GdmqeprsSemAsod5KoSzGi78iFZuijan/AAuRbbPRxSQvsahenyGHZalf 9VUJTmzjckVVWG2/yyLI1dro6cvorWnU+GBlFyseFf2fAbUJ/a98KRybCox5EkCta02qMVoLUQLQ hq0BqOtDXriiIpVUEqx5CorUDw8MDIBTUEbA7Kar9GKgU1dyNFbSSbNxjZgv+qDT/ZYx5plsGM6R aRT2clzcRiS4lmcmVwC/YdTmi7QyHxduTnY47BEzaVbOOTwqeQNdvDbMEZZNoSjzdaW8ItHigVHM ZrRQFO9O2Z+jkeFiRaRW9jbSyokiAcxUkbGuZcshDKGMdUrtisc8q06bD6DmWLIcXqm2maVc38h9 IhUrR5G6Cua7Xa6OCNn6m/Fi4tz9Kay+V7OHj6t26lzxUcQakDkf+FGaWPbOSd8MXIjphauNE0eB Csszv6fENWgp6h4ocqHaeeXL0tgwjuWGw0EIea3DRqFcv9leLtwRv9Xlj+d1B6shhA/mphDpelXE fJYiVVmjDcjWqHidwd8w59oaiBriZcFc0l8waQlkqTQsfSduJDb0J/2s3vZHaEs1xn9cXFzwAFhL vL0Yn1yztyocSSrzRuhAPNg3+xXN/Lk4oL0a7sNPmiZ3toULs3KRVGy70rt+xxy6EjycHJAS3/pP Enh+0IxstQN61Hzyc5Ud3MxbvVNLtXjj0xQRwe3aXmAOX2Y04ZXgP1OPqxdI4BgS4+Kmxrucy3S0 btUAFAaEPQVauwO/LAz2pVj58BQfZ6npkS2Rutv4VZokmhYSMCJFIKnuPskb5C6LeYiUdz9TzTzB +WZlmeXTGBibcRuSCCf2Qe+ZcMwrdqE5R5fSxaf8utaQt+5I4/TkxKJb46goGXyPrUZ+KI0+WEgN n5hTPk7VlNPTO3tkdmXjeS3/AAjqp/3URhsI8byVU8maq2/pNQdaYOIIOY9zv8JXYJ9Rgg9/7cBy AdE+JLuXjy36ZAMoY16DIeMEEyTjTLSSy4tGD8LciTt0zGyZAWzFEozU7y4vrtLy5kLTIwMdOg70 GVx2FOSW1uRzeWUFnap69z1ORIVSIA5lfmp6k4VbQ0QFzWvUGgphW3K6q3FSMUBWWZdhWu/XwwMl xuC0ioo40/ar/DGmBR1s7blRyr4ZSQgxFJzY3AMI+IEqaMe++VSDESIRJnLsyFeNATXxGVkMSUw8 tGSOSSNmJ4kkn28MysXK2HEbDIlYBjQ79/DLythUQLQhlpvUtXxyKQ4kM5QbE0p74V2tYjcVLcRu T1r1G9MSgL+VCKbLQBttgcUqJaT7RWtTU7A9Rkg1mw3y4ptuPtH6MDK6DSyFGqxpz69/oGLG991I eoWJ3AjG1PD/AG8kw3v+qpyRkxKGJptxbbfv2wg7sDG47tIk3FmUh6dVOzBdsJpEBLp/x9dJKK8Q h5MKH9eABnOe9Up84lKquwNCxpXJEFq4og0H/9foKylCqOCFJFD4/tVzJMXVjIRsVNuLPVQSAak9 hTCGo0TYXoojIBPJSeQ79ffATbZEcJXjnzkAHw1BLUB+iv7ODozF2VlWLcgKdicLVZJtcxdKUPKt CpqNhjzZkmP9Jt1CHrzpuSOzf6w2xCy2VFEZWhJJJrxpt8jkS2xAK8hi0pboCaL7kdMCepWKnFuS kFuIr4jCURFHZezUk5bqCemBJNFUjClKA0atBUdf8okYCzjybioAy0oG7nfoe2JTFTYux4DxoD07 fawhgSTsuUrWoJAGwptUj/axZA20aqAQCAQQB8+mKDs2ajiDQg7EdKDwxSpagrvaTIq7sjBR8xjD mjKdmLWOsDS4mtb6ByylpmKldkO/2WOarW6MymSD6XPwzEhsitN826XqlwLeyileQglQQoG3+yzW ZdNLHzcuOO90Jq2sWd9NFDJG8RjTi3MA78i21P2eJzJwj0im3wTC7QwisCfXjlBCCpPTp2y4RnyI ahMVbGIYAru7ftkn6K5sfJwWZ+XUppwIFOTEn3p0zi+2pnxq/ouzwRAiP6SPubaOVUZ24CElwdqV 4lasD881WLIYnb+JuFoOeLTCSJpt2A9Vf5wjCT4hT7P+rl0Z5K2DIcXcqOlgh9ORzRlVQKfsxN6q /wDE1yIlk6IAJR0MMcSkR7KzFz/rOebHMaczI7o5pT5tp+ihtU+qv6mzddhf3/8AmNGo+lIPKlT5 ismC0IZiSPZW3ztZcnXPQ5m9CyYt9gpK4HjUscujuXDkaeLk8ll2pVW9uuVZj6nYYRUXpVtKqw6U hVTxtKUUnYfuwOWXaXcS/H851+vlQCMjPwlQxB7DxP8AZmUXTgohRxVSaOP2lPjkG4Ch/OXlWVFR GrXdh74GRBAoK26SA9UIqpNaUPTIdG4bH+ivBVmAP2eg279K5EtgIPuUOKBq/DV6V38BkmugD/WW XkVtDHNMyqyRRvIOzUVeWIkWfhxtiM+oyGKAzR8ZJoo5aDanqKHp1/yslDIL3bvy21hKzqF+JePo KY/Hl2yfihTgKbJdQSxJFIrj1mCK0ZAoTt8bEZV4ly2ZjBwxtkUXkvQYiecBmk/nnYufu+z/AMLg 8aRYHCCw3WLaGLW7+CONY44pKIi04gcR9nKZuQAAErugUBCrt41wRZgIcGMxoXpVR0GWJWAGYmhA Cnv3GJ2VouFbc0X27YaQDuprN6oNageB64apiebubUdVHQUFPfDTLo4ckUEAk13HfEbotXjqHUnv vXwyCEwilBZVIINdh2NfllZCSdk1tEk4ytwICGrU6A+5yqRDWU0BV1qNzTqco60wtM/L3F55HNaB iKjp0zKw/Sitwn4p1IAI3J9+oy9CsOBPKnKg3+nIlkFIMEkYrWo3r7Hr92SYdVy1SqkEx167H/Ou AshbTlakita9K4gJcIyxU7FRtTDaOG1rUB4r8Sijb7bVpxxQT0dIVLb0IB5be/hiEHmpFgJORHXr +umEBgebYaJYzIQVNfiG1B/11ikEAWpNKVHEL4cT0NCT3yVNZnWwc4YuxG9aEePtTELIElTK+g+x qrU4+Hj1yV218PAX/9DoALtHy41UH43NP9jtmS6kWQ4RPyLIQp3HUdR1xteA3t6W42qDWinpSvUY kM4yDdOB4r1GwI37YoO2wXK6FXA232I7nbbAQkEbrgpZgnHp8ZAPWnjgZ8zVf021jJVVBrCDU0IF a42jh2/oOAqSQ3RifegxSFb9lS/ViHc99/DItoCmEKMxYbEgAnfr8WStgBRNtj4iDSq9W98V5qnA kKpUUG+3YH3yLMBooBWp2oaAdetcVIWhCyBj19vA+OG0cNhtowJKDbYGvvja8NFeFQ16hgdu+w74 CWYAaPHkVBqQBWu3XFBq6aNeY5UcDcjwxWt3mnmQM2u6i5rRNh8uC7ZGZ5N2EblA+Q5ZE1IygUVU kY0PAUEbE15Zqe0Nqd5hjYkP6n+6R+ryP9fl6iiIPiIJBCKtCV+WV6aPJnm2gUkhmkAZGelT0r1O bjhdHxK5lJAr2A+7I0k8mZ+WeX6KjJ/mb9ecN2z/AIwf6sXaYvoCZTLHJG8bcTUEENuKe+auAI3D bZQi2SEBHmDH0ni4ileDtyWn+oq5f4sug/iTxbtyQQyOOVwKFHQgU3VgvP8A4SPEZZAcmQJHRFxT QP8ABE4YqKUBrsNsx5wI3LGilPm1iulLTqZl/wCItm67B/vz/UcbU/SlHkmNm8wwb7IsjH6EbO0k 4AZtfs0mnyOwACQuSTt1DHL47OvmOJ4+KEN2JqD9OY2W+IO4x/S9NWCT62sUqqPq0ACsp41jB2H+ vXMrTGo/1nU64XX+crx1bt2LA5lF1ACrHxUmRhVRU1PfbIndlDY2V0TH02fcvTc+5/5twENkCaJV CrsoBPKmw9h4ZG2RiSF6uoSg+ydlPcH55EjduEgAuei8YmGxNORNTSnbB5pO3pKF1dhHpeoM4o62 8xU+I9NuuMeYZVvv9TCL1JFkt0pxKW9uCPf0UqcplTsxyDSg+g5IoSQFB/HIFPR1q8n1u2h+1GZo wyDv8QplmLmwyfS9RP7wA9/lgaXm+oW7TeYNR+IKPWIP0AZVllTLioIC8tKtTqAafTghNYkkJdNZ NuQKU6jLRNJkh/Sl507eGTsLxWozQsAdie+TBWlqxSv+8rSuxA9sJIR1REUbAGhpXrXIkthK14JX +yDUYgsDyTKDTb10DGFyhAPIqe2Vg3yYmQARUFrdK7fBVlqOJBG4+1sf5cZwIFlAnE9WQWcMiWXE 1KybsKdcwpHdZWqekDF8ClAPhLHpXIA7sRzR3lN3EcoJHHkKn2pmdALe7JOJA+E/DsTliab5cDuA Qw6Dr1rvgV0gRQX/AJ99t9q4QxIAWEs9OQ2QbnuaGuFFlclWerCgJOApFuRlRjyX7VK+2KRsp1LO pGzGoY+1Phw9GHVorVya0Zq8R28cIQRu0asvFh1GxHjgSeVFZ8EY+Or8gTSlN+2Sq2vaPNqQVIc7 MBTbcDEMZDq2jcSjVoxajE9BTFkDVLG5FV48Wk5EqPYH9WFibI2+p//Rn5ZwqoKq3RgRQVzKp1Bk QK+lVdVbjuAvUuB371yIbZAGlodgUAoHqKkjr4H4sNMCeS6oRq8jT9nbt41+zgZci2qFQNwVqC5H UbbfjjaRGm1VWYrTkRU18PniyoXSrVlic8RxJ2PUb/ayPVn/AAlympY0rUBTUdD26YlMd1zqO9eA 2oeoI8MDIj5LTuBU0oKk9/5cLE7tREiOgJofhqAa+OEsYHZcq8QWG3LqvanhkWYFbrRyqo223JPa pwsN1/KqA8t/2ie+Cmy9lnN6MDQj/PphpgZFejEHp28CO3TEhkC5NmYkVIpWvU08cSseZaaoajfC Kgn5E4GRLy7W5jJqmqSb0MjDfuF+H+GRmOTfg33U/ItZLi6fYUt5qClekbL0/wBlmp7R6O6w7RP9 fH/ukTq6g6ldKlCvI0oCNgAOmS0gsBhqJHgZH5T0a1m0VormJWWVnYllAbbpR2HLNzPYh54b+5jm v6Wmn6kbeNj9WdecBbc0PVa9+Jyife5EJXFknlsEaRF/rP8A8Szg+2f8YP8AVi7fD9IVZtPMlxJK FUBhH9JR2d1NP50+HMKGao05HGR1Uv0VKZXlaUDkrLxFaDl6gXen2okl+DLhqgBQCOJdFYzesJpO Mbxj01XbgVCGLl/rHlyyMtRceEeriWUgirS0EUsjhlZXZmFK7Vp8PXj+zmPlycQ5IB2QHmyn6K3F R6i0+dGzbdg/3/8AmNGo+ljfl/VI9J1Rbp0YoqMjKu5+Ica7521W662Sa75t0H9C3UUV4jTvBxSO h5Fm2UdKfDmRGJtxjEnZ51aH1WjAA+ORF3NBu6jMbKfW7OAoPT7ovHrNxE5FBFHQAbNVnfMvSxrH 8XR6870iEIchRtUnl/qnLi66Jt0wLmqkiNegbvjHZE9zt9KqpAiBGwUFiT4nZv8AhciebbE7IipQ FCPiajAAdv8AKrlbkchTg7GMcVHEbN7g7Y0vEa2Dl5yBan4h+ydzvjyTG5Jf5lf/AHA6k4BIW3lq 3h8DYwG6ZG2N6qoOpEV+zHECfcRpmK7YckJ8UbOv7Kmo79cJFqRbUciW15DcfbijlSRqeAIJAyUD uwmNqZ4fNmhRhJJLr0kdTT1EkXYH/Uw8JamL2sf1q8u7zf0biaR08eNfhb5MMxM8t6Ynk39XjQ80 Qj4q/H+12+EZVbWSVk9iXBZUFCa4RJlxUgpLWIMAF3NR08MtjJRJDnTSR6gFa9qZLxE+IptpZBoq 7j+OT408apbaWHf94NgN6eORORZzZF5c0O0vLhUkTiENSDvUDKzIkgMY3I1bNJ4I4UpBGFAGwH7I GwpXMiAZz8kruNMguVcXCl1YEl+jqf8AIYZcZONHGYmz6kktDOs1zYTH97buEDMN2RgGjY/7Fswc 4Als3xkSN0QfTjiIcVTdSAerdMx0jZEeXYljEqBaLXv7DNhjNhgDZTpTsCByU9RvlpUFUHChFAOX 2Sa5FmsA24n4Bt71GFi2lSOSCgOxWnfpXFY7r5KlVUA1AHTriEy5LOQIR6UYkqPow0xEm6oQRxIK bineu2BNqTuOShQfl3Fd8kA1mW7mKGhNF47fDvUHviEyIWtwdxStAtd/fCg0SpvsKLste3fCGuW3 uWvzI3HwVIP4YhjIk+5UVoloCSV3QBdzTr+vAQWwEB//0uhvxdfiPQElvE9BmQNnWSAkN1MKYyCD 3IavTbJXbSImJVSi8Oh9RRVS1DQjxyILeYiv6S5OBjo5IkYVY9h/k0wHmyjRG/1NqplXfblQEDap P2cTssRxDda/ddwTUNTbYf7WEIkvH8u5PUU+welKYGQ7m+QBoBQmv3np1wJEqbRjQhviFD/acUxP e7deBBrWopTxPvink5VrVBVf8rbY9uuNsRHoPSuqZNuqx7fce+PJlfEsdlDNUdhQDceGEBhIhcx5 xigNB3Ht/k4OTI7htfhX950buOoIxSNhuuDbEE8jXt8qYpDXE/DRgSAAadcVpokqfs1boW8FwL1e WaqK3GquTv6snXr9o5CR3Dl4G/JKlY7t+QQCCT7TEA14qOPH+Xnmo7RO9O6wfT/yUiiLuQ/pS8mU VHNztVhtsTv1/wBfLNGOTjaoej/NZp5cmNzpSTHiCSQFU9KZucp3dDjjsWLedJg+qwwLsbaKjdK1 dufH/YrlUm/HGgm/lxSukxe7OR9LZwHa5/wgu6x/SEdJEGmikBK8CSaEiooeo/1mzWxlQIbUA9re PCYQhBE7yFuQpwPMIP8AhlzLjlhGV/0GZlRu0QLFpHtzPRkjhEcqHcMRxb+GU+MADX85gTV0r2Fu be3WNlVXFeXHp1JH/C5VmnxSsMibQPmiv6MG3+7Fr9zZuOwf78/1HF1P0lhc6LQMOjb52sS69JNW h/drx2FQQPw/jl8CytGaFEDc2UdNmniH/DrmNk+tuB9L0nV246vMASW9NB9ntVt82OlHodHr95Ll cJERUkkdTsaZbVl1oVFkNVLmqjsT9ORIZCR6qhdnfYUqfhGRpkTZRKsdi+xU7kd6ZAhvie9UAZoh xoFTYjoSa8hkTzbRZj/VajZjKObfCB26U9sB5LEni3S/zW7p5Y1BYxxQwPyJpU1NDT6DhgLk270A PpYv5g+DUZWH+SPuRV/hmNDd2KDt5DLEwUfECSSfAYSl1vb+n9o8lJqtfE4CU0zG80yGbRtPlljM kyKAniK8eX2sxpSIacm3Jbc2iwhQuw49Bt0HtmPbUY0oxj4RUepRaivQGvbEsaXzbIxp8/YYpIQp iRkWRQPg7nw8cNtZj3LQvKMcB8JPTxxtjRWG0Dn4NmP2j8skJMxFcsGyrGd6nmPYYeJieaO0i8a2 vlAXYqwDDuSO+WRq2ePYssDlkDNVlYCg2+dcyg2ltI/VatAp3piSgBhEtwlx5h1GaA1hWRYiwNat Cqxsf+CXMbUbUxK9JFYyKegboe4rmOsBZTjQwSszHu7KPkDtmdi5KI0U4QsE2p/KfGleuWqGyehI r2H0YhLaklq0PD3PYYraziYwKE1PQnrSuSYDZeVALOhJIFGrtuTkWRUSocLwOyivL3rTJNdWNm+H RmNBSpZdyCcWRCkAo3Hwk779z9nJFhGmkiQUIcCvIEkdsSWMcYHVo8gHoailMU0d1oQ8AW3qw6fx w2wEdt1x4nnyHbt7dcDOhvamqo1FQdNzXb8cLAAHYP8A/9PoaqVjqfDfx32GZB5usEaDnAdQ1TSv xd98RsmQsW5iSop1c1NfCmIQTt/WbRQTRalQac606e2JTEXyXOz/ABKoomzV8D/zbiEyJ6O/u/hJ 6/tdiPHFR6dl/pMkiMSKEbe+RvZnw1IFUQ1WtKfy17/LAWyJtSbiGCgEHrQV37muTapEXS52NQhq OOw8DkUyPReWBUqqgj9o9MWV7bLGoF58qKa08d8UHvabm5IU1Wg5VND9G2I2YmzyXqONQTVN6U61 98WcRS4Hm2xFePEkYOSea0Aq5qBQigp+vCjkW1HGrM1dvhp1qd98UgUpyMqVJABqPhr74jdjIiLy e+lpBfyEmrSPQncn4jvkJD1OZh6Jh5DUm1vWIY1jVSUoK8pYq/b+1/sc02vPqdzi5D+v/vJKOoPL /psimp5SFeRC1JY7bfE3+rxzI0g5NGruqVNK8439po8dja2wS4HIm4kYkKWP7MS/81ZtZkE2XUxx 0EsT1ZJjLM5kmkPJ3YliWPU1OUyNtnJm/lyZW0yNB9qOoYfTXOH7ZxGObi/nO0wm4hM5ORjbgQHo eJPY02zTDnu3IIi9MK0b9+JSy7bFQp4xv/r5lRMBL+hwpFOh/SAaMEVT4OQI33Cczyr/AK2M4wIJ C2ExFdsxOElFhI/Mt3C8K2iMGk5hpF8AOmdR2HppRMpyHC4uol6SxSfiARXoNge2dQHCSbVyPgXp yIpl2MKDujvLa+pqumR1+1dRfg3LKZj1EuRVgvQtQYS61cgHlJxRApoANi9PxzP022N0GvNyCmZW JDEig2O1emZFOvVm+IFq8uX0U2yHJB33Vl7L92QZIkNWh612p9GQpvBXGWoCFePJtz1GRps472dw NCS2yGhYdPHbG14f9il3m2Qv5au+f2ZUWNa9l5pjjFS/quVCdmJ/npF5giD390w4jjIVIHgvwjMS OzsSlq+lGoMZoD1rk0ImCeNJUogkBI+Hv1yMuTK2eXdWsrVUYoCKn5eGYc+TVkFpVdLIEK8izePY DKg0yCHjm4oOP2N/w3bDSxNFoBZVLGQgOeg8B0yN0xO5ta9KiNQeIFCT0xAUtpSnpg/Z79qHFSdl zj024Idz0xUml0dqjGpJDd6eGG2IFlqa3hRTw5VBqu9ByHSuSid2Z2S+3836rpUjRS2v1215HjyY pIo/yHo65niQkPNnEgr7zzjrmrKbTTbIWMbkB5+ZeWh2+Bgsax4TKMRdpkQitPslt7dYlryTY133 /a+KnfNbklxStxwCd0V9XRyG4gEDr3xB3bIg3fRG6MrASEMaFvuGZ+D6EA7psFXkq1ND1p16H/jb LlPNeSrVjoR/LTxwMm1UHr0pT5UxJSAtovqOQaqRtvuN8LDq6R0RDyFXrsB4UriAmUqCi3InYEBg DTbpkmor1UyemV2FeODkz50sr8JLUDct+/XChYOLVC/arv74WAor+L0ZaioVq12pTAz3pSFVWnKo oOQG9SDywtQBAaKlWPxUJ2Ph03xUii2g/lWq1ohHUHFQO7k//9TovEuVYbg0496AeIzIddV7tUKk V2A+LkO3Lr/ssUclxWMSEIoK7Hc02xWhezuLqy0INKCvTY+IwJAIIVWZgxHH5GvbA2yO61ywda7s amuEMSd14ZvhVyCoUGopsDgZW0scqkIQQOXwj5+GJIREENnhx5UINd++3yxSaXndqtuACaAbD22w JWU5IFACqu4NNz9Jwoqw48DRjUgihJ8e+BNBtApPxDpUk/LYYlQHKaxluHwUod/DCgcmvhYAINxu adzSuKOfJuhJFKVB+EdB0xS5WUxnfdQNupxSDso3lPTLV3G9KV2G+GLXlFh4/cyiTTrgkgFtwDXo T7ZGQ9Tn4eic+Rv947xT6fps9vyDI0g3lCn/AFPsZp9fD1O4xHb/AE3+4QssoWK54qByLioFDxZi f2h8OX4IbBxdVLvQVvx9MU22pmYXBCsoof8AjbAqKtry4s25wSlD3p0P0HMfNp4ZRUhxNkcpjyRP +ItWIP7+ldvsiv6sxP5KwdzYdTLub/TuqdDctQfL+mT/AJOwjoj8wXDWdQYEmdqbCvcU+WH8li/m r+Ykoyajft8JuZGVtvtHLBpMX81fHkpsI+KMT8RHxV33y8Cmk77oO6kWo9++Wx5Kk+vOQsBHU9Mv w9VRnkWYv5p0qF96zIQPdVLtjliOElsiTTPL9+Oq3hP2eYAc+PBfi/4bMzSD92HRav61scykADoN vu2zIMXEIRsThUCjttlBDBExHkaVpsdzlcmUdyiIRHSjg8Ru1Nsgbb8YHVr4atT9kfecUCrP9Fsi Uk71B28Ntjjsne0t80h30Oe3RWYvJAiU3pyljGCPe5EZbgD+ckGtyTDWL2N0Kgyvx+QNAfwzEA2d sgpEBC0GSVF2IAmhZgOYag8N8jLkln1wKWNqWHRNz79Mwp8mMknuXWNSHcb9u+VhpKEt3iZeNCqi vX364S1qhjiWIEVHZflkUxFi16Rlk60p2PhgJQNwrKkf2RQk9aeGC0HuVKKhHJAQe/fCFJWiM+rI 24UAGnviZBYDcuCGQlCAEI64LZyFqMlnC4KOKnoKCuSjKi1cO6pHZopBFNt6nY/djKRpIiuZ1I9L ntWpFK4BG9030WyTRxQuR9lVJPsKfD/wWTEbLZFF6G3KDnvwbwzYYhUWoc07X0zIRTcgEE9qZNnW 7Q5cwFFS3h23x6Le652ILcTSp6eG2ISVI0VuTVqSfx6HCx5KTglfiFDyBPiKd8kGEtw2oR42qaNs adsUbENrLReHHkQCN9qb/D+GAhkJVspkbjlU16+GFiRuu9IbyBtwRQ9OtBt9+NpERzaYkhVUUAJF T4ntipcwZXqKbblT02OKm7anD+pQ78PhFNhSuEMJg20opEGX9o8WHbY1/wCI4lMeWz//1ejNyjRK Cm7AnptTjx2+1l43dfLYBtVjkiUV+Ikbd6e3zx5FIiJRWoCGBQFVNAPEf5OEsIijsvB5VbbkSGL+ wwMxvuvBB3Iqo6iu/wBGBnzCwKWAIAFKg8tz44WAFqgI4mnQUBFPtGu1P9XAzVEYsEOxLALxau2/ XIsgdljJ+8CqtB0Yk1A75K2J5todysZrXqF6b4CyBHRplodyQy7kHCim+ooRVVB3I23+WBJ5OKJ6 XxkgNuPkOv34oNU0gXqn2SOp6jrhKxro1H9osNyNwp+VAdsUAL6qqqwAqwIJ67k9cDLYOogBpUbU 7mpOKCAoyw+qhjrQMCCfY/DkgaQY282uvK+r2t5NbraSXVpUsHjIoyfscqfYdf2slIA7soZSDR/h VrHTdZs2/caddxcmVmVCfiKHmvf7K1+HKJ4BLmXKx6zh2p0ul6k8ZiXTbgOaVLjmSdyf9Xrko4gO rGepMtkEfL2vKxrp89B1oo/gclwDvafFPc3+hNbYCmmXJJ7cabD/AFsHhjvZHKrtoWt0UjTpgrdN gD/wJPLAMfmviNv5d11SWbT5j2HHiR/xLHgC+ItfQddQjlp05B2/ZI/4lh8Md4R4tdF50bWHVUGn TihNKAAb/TkfC80+ItGha2UZ1sJ+C9WoB0+Zx8NPiBCG2vIw3qW0gINDt3ywaYlr/MR70FPFPyI9 CQd6kbGmWDSyU6iKWX1rdXrxKilOBINdv15kY9NIXYWWpBGyO0bSNS0+/g1K3lVLi3YFCQCf8rZv hyZ09ii441chz+lk0tzNLL60r8pWAkkp0ZwAv2aDj8OZWPGIxoOHkmZyJRNrRj9qgrQD3yM2oo+G QiVShr1BP68okNmN0UZDXkO4H8N8pksTuiyyjiG5FSPiHY96LlbkEgc2k4bVGw6juThLCNK6hpF4 opHYpTffIHZvAJGynf20dzCYiWjLAUdTQq6FXRx/qMMQylQIKzUdFs9UEdxJyjuwAssidHP83Gn7 WYwhwl2AycQtKD5SdpisUyiEbhyDyHtxGTIFIjlJOypp/le5WZVu5PTCbiRRXru2+RmBWzZHIb3T PVdZsLdIoEjmuuI3MaEAUP8AMw+If6uQ/KykGE80O9Jbi9Sdgy2VzyP2W4A/hkPyU+9pOWB6rUmP EN9SvKr+z6YK4DpJ98V8SPei2nYqD9Quio22jH9crGjlf1I8QKJkueXKKxuwOhqg39uuS/KEfxLd rlnnCkrY3HIODQR1IHQ4nRHrKKBIIlbiYMxaxuutd4x08evXANIehZGVL2u6PxezuVDDdmQUHL5H B+TlfNfEA5uk1C19RgkF2zqdwsR4n/guOE6M/wBVlxxKm2sWVCgs71pQeixV3I+eP5KQ3tRkgdkO dZhAXnYXisNlrFXJ/kpd7EZItLqFsW5/V71a16w0GGOjl0PCnxId62W6trhfRuI7mOFtiwjpUf5W TGjkCjx496e6c8KRr6aFY0GymnL2ZqftZf4fDs1DKCbR6kgU25UI/jgLaF8UwjYyk1Crt92JFrxV usErymrk/EO3SmGqUSJcZfhLEfDQb9aUxpeLa+jSuH48tlY0+Ve+JQJWtotAehXbFFBe6gLz+RJH U174pNVao6q6UHwCg4L7bVY5FmRYUYyG6g8BtTJFhA24hWoVO3cHxI+1iih0XFSPiPdRQduvbEFS C2zp6bbbV3B61r7fs4KZWKaTkWolApINfHxwlI8n/9bpTgcDXZQQeNa02r1y4OFIbbqYYKA1OLAf DT55Kmu6dGW5gMPjBDk9e1OuJWNk0fqXgqGKoBxI6UqDT/KyLMbGgtoQASDy6jCtNBgzVYVrUkDr hYRlZVeJWqN8PKpWvWn2si2ctlQAkxuaEgnr3/lwMwOq1lLbKPtCtQOoxQRa6NYw7ODQq1AemJWI FkrJWABJNSD8VO5wgLI0FT/dLghSp7Dt74E1YU2Yji4Aahqvht7YQxksZi5IGwYDl4YQwO6oG4qX cD46AU2pTAzBoWW2A41Y9KkoPo44ElazIV3rQb+GFBIp1GOy7nY0HhTFktqzB+GxpTj1NMaYXd0p mNgxZlqBQEjamFgYm7XbghQCWqKA07Hl/wARwUy35LFD8tpNqk18BX/jbDs1gSvmv5pQcPh2oZP2 q/L9nBTZfcp0lUgE7jc+JHjXJbMBxDmtkZy/EPsOhG4NfDCAGEpEmralAMSmgFCNh1NOpOI5rP6V yxqI3dn/AHaD4iRTiP8AKx6shHY7+lAahdM6LHDtA5PIigLFT0Kfspl2OAG5+poy5LFD6UtmWsXA 7Empc9Qd/s/fl8ebjgoGaAA04/7IZdEsuaWm1DShlFQW2XvXtmRxbMrpUVyV5Hap3GRIZc2nMLU4 yDfqD1GEWpCKs/hqVIb02qT45XNrIR8VQV2+Km7DuSf+bspLWmQcuOgViaAjsBtmOQkmyrEs4QDs DT5jqchVM5EmkRE8aMr8mYtUtxoDWnav+VkSG2MgCD/OXJyUsWqrdgDU4C2Cxa5/Teg5EU236Cn2 sAtZUW1lZG5r1G4I/CmAhImQbWiaXgADuTvTbDQYjJKl5lkJLFiCOld60wUGfGedoOSMueQAIJqc sBcacbNr4qKwAAB7dsEgygd1RN+YWlajcjw65Ehsj1ptUfsaL7HG0iJVSGDBVrtUE7ncfLItpsGg 3wJjBrxFSa0I3OKaNNSA8gUqQAOZPQn2xCJXezZjXZQ1CCS5G/gFO/8ArYoI6W54kjQEE860bv8A OmINspQ4RdrhHBwVjGwYkgGpp064LNrwRqyFFrZnIY1IpU79MkJU1HESuS3Zk4jboN+2Ay3ZxxEx pDvCSN2JXx7ZYJOPLGe9fBblOjAAmpr3AwSlbPHiI6o2EKp8WG1T9zZWXKiAGmBMLgUIJou3vviO aCLiVy1WEkj4WqB8v5sHVn/CpkKHIVqKKlB8u2SayG1JMiq32WqN8Cb3po8o0Lgip+Eg9KH+OEbs ZWBa5R6aHkD8fU9dq9cB3LOIoOZN+SsaOBseoGIKDHfZpIw3xiq8yaCuElRDq5VaNXU0oO5Hffvi d0RBiCrAMwps1dqfT2PzyDbVqYWjipG7D8OuG2NbuYjnx48U7EdeJ+HFSaNP/9fpPIEhOPwkjk3c ClKDLnAuzSnQlgAvwEcQzdaV2rkmFHub+IJ9o/aHHtXq2LLcBUfbcdzWgGwr45EM5bLmjoQw6A9a 9v8AJwApMVOkgUsVKgmhpvt45PZq3C9ahf3qlmK7E+BNOWR9zMeao4T4qA8BUgd9+mANpadlMdV2 NaKAe3THqg8nIzt8B3INKnY1wlESVooaEDpUjetQp3xY3a8EyHlQcmJqOm3XAWYKwAGbj0WtAPav f6MLGt2mQIF5NU0r4d8UEVzW1JHJj8IBKkb7nCxvqqpV+vQda4Gwbqf2jVRsTWg8MLH3N1IAbufi 49Nj2rgWysiYdOjVrU9cJDGEl3HlGwFabUr4+OBnzDVOfFf5a/GOtfpwoq25HQKyKtSV3PXc/wDN uABTLmAoo4RaHetA21fh7EN/Nk6ahKmpKsQ6H4fs0PUj54hjPfcLfTNU5MVA2HsuNo4OVrqpHya4 2VdxTc07Y1fJlYj9SX3lyLhiF5JAKUSta/5T9svhGve4mXKZHb6UO9KUUbbUAyYabUmXYtX4j18c kCtoeahionTqxPUU7ZOPNkOaBZGC/CfiqGNOtR0OXgsgUJ8PHhSgX8csbQC1zPCtN+mGt2SItwaI i7uQeXtvlcmEk3tkPADMWZcco2NKHf7PUfPKiWQG6IozMPhpt0XwGQZkElWAQU4fZpvXx6ZFuAHR cOTBpDvQhad6/tYE7myuUOw3A6BFp/Mdt8BLKIJ/3CsFIk4EAnqxPj3pgttA3pQCmM14kmopy6ZJ pAIaargL4VJxCDvstICDbfvQ4oNALGHxbb16fL3yTA89lRCjAr3FRkS2xIOy4RhaqWpTYrgtPDW1 qkYlkGwYgHkOnyJOA0GyFlWBITgSaAFjXua0GRbgaCwmTh2p1AHamIYG6dEC8i7VWm/b54SxhuVz ryhXueRHfAObZIXFvhyZR9oADG14bK1VrIHIpyNDv026YnkgDe23UKZKmp24jwr03xCSOaGPIgr1 Unfwrk3H3Oy8gUBB2FBTrgZKsB5OeRA96bb7YC2QNndUHFRwU8id69PmMi2DYU1HGeBCsSoNAD2r 23xJREbNSDhIdqGnbff7LLhHJEti3VlJehp/N3rgTyWAMUA6xrUsPc9MLGvkvc1SgHwkmgr07UwB J5O4tyWnw8lpU9NjTDa0bXgqV6UZengci2W1xZo6Psvt3HjhtiRY3XogJFT0WhA2BPjgJSAsaQgE harHQ0G/+thAYk10+lwKsHdj0ofY0NScU2Du/wD/0OkPQseIARSoLeBH7OXuCef9FczEcedSpApv 2HhgTI97mZDwpuKiteo9sVJGzpGbou36qV2xCZErVYvWu9Ad+2E7MYm1/GpV2eoUUIpQk0ry/wCC wWvDvZLf21qB8NQp79t8WXMLiAFAp2qWPXw40+jAybHEEUoQ1Kjpv1OBI2cpKgs6hlINevTChqtP jp1P2a/ThQ7lyAB/ZIG/vim1gABLUJDMeP0bYsAtmLKpBFCPhFT1PfCGOQ0HRCg+zzQb0A399/8A VxKwG39FeQQoNdjuanfbbFkpgAig3aoBWviK4WLb1Y8U3VdlPuaVwJO/JTUDkdqgbg4S1xG6swlb psadzx+/IhuNrWYcQeVWFQ1BTbtv3whgStCBQSxI5dx49lxUCuf8S3rRXFQvxOPeuFge4/wrZACR +0D1X+XuMIYzCpGVXaQcnNfTQGhA8SciWyPcfqS+ctK55EEUIoB0ocvjsHBySMjuslVURTXd9yRQ bdMI3LGUaAP85SkCgngSVBAUHrTJBga6LHFI6ACrDc4RzWkO6CJZGAqi0NfHLAbSQgmjVakH4iSA D9+WgpCCdWoqtSrGv35cC2iS3h8agDkv7RGG1TCzg5NzUD5ZROTCRTWCDo9CKdsxpS6NcYnmjYo3 LKeNePTKiW+ECTyRRjJcAgqNySOtT+zlYOzkmFluOAGrU+yN/fEyZRx9V6pxLFlBqOnvgtkBS7gE TlX3+demC2VULcRUV6nc06fIYVW8nXiXNQK0WtaYsASOawV5Gg6jb6MLHqhpSQfEnr7ZYHFmVQqC oLCm2RttMdt1sTcGLqKGvJWPsaU/HCWEDW6oeIAJOx3qfuyLaaq1SNzCEkI5AYCLZxlwgFsyMwWi ClT8ztiAmUia2XRkIobYdQe5yJZR2FtLIqu1a8SKg0+jDVoEqJVZG4txY8Qorse+RDaTSmHZuX7Q UA7HJEMBKy0QFC7VU7/LFFU2PhViSCTgZDYFtKoPiTkgNadtx8JxYjZYqFFJI57ipP0YSgRofzlU EvKAFAAFWAwNgNla0dCWFVLbU8BXbG0GPVYa0J3qx3Hy+zhazaqDyEZXcqPiHSvzyLbd02AzIXc1 FOvv0XFO9WuUsKg0JFAQe+9RiltByWhUEDkT7HtgS0w4yBa1AFR+r7OFHVqtDxoOQNQT92KC3ITW gAUGnEfTiEu9UpxXYggmvtXBSbppWqGZtl6kV6gYoB6u4AFVr8BA4gb1rhtjT//R6SAobehr1A7b 5c4dB3pvVtu9dt6HvjbEguBjJHLquzA9q0o2K7Hmv4gKNywFRXtizrZqNQo2PwkVbj7H/NsSWMRT agMmwqR1buVrXAyAsNbKgU1FRU12Nf2sLEbbObl6tf5qf7WKd7XtIdxTcbbdD/lYKSS0zOQqciVF eX+ffCg22XCoxKVbqCPu3xZE00wqpLEii7HxNBtixPJYHcOIwaAdz74WAkbpo85iAtEUA/F7+OPJ BuXL0rqMQUBIC7s1ev8Azbiyo1X81cAihi1DsBWnjgZgBSX01ddjyoeXuDsKYS1AC22UxkMGXlsd t6Y801W7kCs4IFFau3ao6jErGiVNpJC7CvwqPiY+J7DJUGszkSf6K5i27Ej413HYU9sDM3z/AJzj SUgEBQpD1PiRg5Jvi/3bUSs0gVh1HOviD0wnkwhZluskKoeA+J2G1OnXqThCJ0Nv4lrVVSa1l3VK b7d2woOw/poZi32zSnUU60BybjHvWTjmSwA4tXiO+2+Sjsie5tTaLjwAYVJ25dMILExWcA1Qo6AA thtiELKZJR6EdCigk/zHLQANynoh543jq37PgRvU5OJtAOyHMRKjjtt1O+WWkFZHa8v3Ybia1B8c Jmz4k7tLQUVUXcDc5hzmxAMuSYRxMq0616ZQS5EYmqRQVQASKUFD88hbkcIX+m5X4d22p9OAFkYm tnBX4sASKjcjFQDSqoJoCwJG/wAqDpgbAGg3L4CtDTbwqcLG72WsACGJqjncdCMUH7GmRAVoNh9J O2IKmIUiTyLCoFO+Said7U2Sqnx8PY5IFqMdmom5Ap1XviQuM3srKoBK/sr/ALeRLbGIum2qVCE1 rsD9NcCTypaqp6fLuaGvv32w9WIA4V8QJ/dkc/cd8BbIDoVrB6sgBoPiHjigg8mxStKtupJr/wAa 4qOaq4Rk5qORI4le5J6Ng6syARayPjxoymqkfQff7sMkQrquozJyGy9z9OBPMLCOLNWlQOJUYseS 8823pxUKBQ+AOKdy0yFiRTalfke2IKZRtc8ioStKsyjc7U5Y0pmBt1aJoVIXrtUmorv3xAUyU5KM oI+HoCR0oMIYSohteQVtvcfLxxUE0iACOIBIoaGnTrXlkG5wFSzEjuAKdaYpd1C1WjGm/fFWnO/H jUrWvfqcIYkrjy4AH2JA9+mAMnKzLUvUsKU+Q74kK4AFeTDxG3z7Ylataa8QAK8NmYd8UKhUsFNA u+1Ox64Amrf/0ukJWRh0Ugmpoentlx2cGO5XKKTFnJ3NTXoOy749FAqW61nQtwTqTWpFfwOEBBkC aC4cuCow+GhBH/G2LLpRaQUAWhrtyPT4Qe+AoiKFKkXFiVHVe4NNzgLOJtbT98eW/Ab+Fe+HogfU 2zlhSh33HjXFJKwF6EHelR92FhuqKo5orGjUryHTpgZDo6MNxdWPWgPiK9QMSoHe2eRUdatQk9qj xwJWRxszKpAXY196d8kS1iJajAHKpLMV6Dbc4lMOq/kG4KtAaUavWtfHAztsvU1jA5bGjeAxST3K EYBI5MQTWtB03yRaIDvXMp5UVqhq7H+uBkRvS16RIeANeteor7YRuiQ4Rstj2YHcMfkQaYljj2LU o+H4asQaA+1cQs+TZHAIUTmTUhR4jCvKqDRNEZ3bixBEdfn0xRI7WT/VUk40MzAoi/CKbV2+EZLy a419R9MVJ5nKt2bccvDpXJCLCUzRWOaxkKvEM1OPyFcI5tcuWy2UNy5k05ndPlhDGQ3tZu7Cgqep HYYeS3fJq4aMD0ozWNFbjSgPI/tM3XGN8yylXIfTFBNEyycWBDU2b55dxbNXILZ2qeA3PTfpXDFC mYqqqv1H3bDDa2qwwoHU9xkTJNlN7YNwCnaldsxpc3IhZFJgsTEUFKr32pRspJc4RKqUAYotCe+R DOnAbFVFa1Xb78VA2ppAC5qoAU/hhQGzQMGNaDpt0BwJOy5o1G7fD3260xWSmTQ1PToPpyTG26fD wZQCTUEe2BNbUWngT4iDsU2BPcYQWJxhSHGhBWlKih69sLHalKHjHISP2qj2yRaMdAqyUFduJI3r 08DkS3xCmwNDxoa7GvY+3hhDXIdyrGEBIY0QUG2+xH/NWRLbEUtFAKjopqT4UxUU5WYijNUE7H3p jSgnq0AxG3ZgB92+FiAT/planUHZq7kmle+RbipVYiq9SaMOoqO2Satzyaqu383LYDbc4osKhQcT IdyBUH36YLZkdVzbbDkCRRq9xXlgCS0AakDoSByH68K7u4sqHaqg7E/I4oogNsFaNTStO3/NOIZG iFF2XkEQbEbDvthDVIjkF4oHAryWhUV7D9nBaQN1dFAVdzzJDe2x/wCaci3UuoOXFTRidvah/wCN hil0pRxtu5BDDw98ASVkcTF3NdwdmO21MJLWIkLkbkvCm68uRPemLKJXrUNU9SSD3pQYEtLQk1FF 3oB+rFQ2vUivwn4unh0xSsHNnqu1D36dd8JR1f/T6PXgCftUNKUod/8AKy9wLrderUqq0KvQiu5p WvLAyH+6aUq0g6niasfEdO+FAIJXSUZzwIFSfbbrgDKTSksrOW2NFbv9GJYg2LXBS1KUFASSRizD uNFY0IJ+x8vcYFAbLu55sePEAgdKnFea0gDgV3969j/N/ssLHupU5UjVGABJ2rv92BsvZsc2AHgw JHsBSuKuZivID4qdCegB70xQVPiASSevxUHXr2wsapYtBLVj8OwHyP8AMcPRgOa8kBwAPh4k/wBP vwMyac5YItfsjx2qpP44oJ2Uxx5ljulQad6Dqo/1sl0YdbaWsjEqdq18Ov2R/sfs48lHqNtuR0Xi OJB4np3BwBMitJUKoGwYUNOpqa9sLHYANS8EXYVJPw9a++I3RkIi0g9RxuQtCXp2Aw8kD1OkqayM GAXYE0G37KUxCZd6hKzTPwTYDoOlD3Y5MbNMzxmgsevFqild/nTbbCGuXIrHJqGHw/P3whhIrG5k mVSeA2rWu4p2P+UcPkpvmpzKyLxGztvJ479BkolrlspoVofUO7AqBTfp8OSPkmKxhU1NeYNDXrt4 YhBLSckkZaguaVbrscJ3DFaKEnl2Gw98JVVhBYCoo1cjJKbQqGYGpBpU16mgzGkXOgLKKTkVIBoB 0B8BkHKHJUjLGhAqCRWvge+AsoldVw7jkKnaowJbWoJBHwAUPjvioWMaA7V777bDEIkdmz8SFuoJ oD237YU8w2wUjcbbHAppRcuKMprSpp2pkg1zJVDwCggdgSfYjtgZ9LcwDoFoSAak9a9tsUEWEM0P YbE/Zr0qP9rLLccwVEIccyKF+gPauQLdE2L/AJzpE4qCfsHYUPUjxxBRIbLWIPFEHw0HI9K/5WFB 7gtegLU+dPE+OKJU4gFG2+KoJPiKdMUHcLoP70kgvQVK+1MZMsfMtxstCrktUfEf1YlMSORVGFUV SBSgevz2yNs62UlL15ABvi+zSlfGmSaxfNcxBqxFSCSR7H7IwMiuqh+IsQPEj9WKdua2JgeO5HGn wjwBOJDGBtUD7UWrk1rUbAY0ztQZ1UKQdl703+WSppMgN3MAZFZO4JI8Meinc7K6gBeSihqCo67A b1yDaOS9Wo46kb0A99sDNwoeZIo3VffEqvZWBPAqZKcRQU6/zY2kjq0JCQwbZPslaV6YkKJO48iK EU3/AA61xULyVC7bEV+kYGTaqynrVTUU67nrgYjZYpV+SH4aGnzFe2SVcClASKMNh70wJf/U6MFY ijgjkRU/xy914HevkHDjQ8gaqPegpiGUtqWrIacqGpNABvSh6Y0gS6ruNJSRX7RBHepGLKvU0gBF Svx7lad9+9cSxG66KRq8yTxGzffuKYCExJ5rEdubMTQfy9/Ab5IhhGRs2rMY+IUH4uh+j3yFNxkO ToRQsVoBQAA71IPfCURDqVYA78amtf8AP9rFW1apLFaV+z8zgpILmAB2pVqdWO2FVnwgFgtG3AxY lYEPD4jVv2QO2StgImt1QshQryJLEAdMjTZYpaxAR67dAG+XhhDEnZYVqFZCanYitenfCxI6h1VF EG29R8z1Y4FFDZTlRftA0UAca9euSDXkA5tpJTcbkbKpFQK7DpiQkSpuhlZduIFQaGu/7W/0Y8l+ tppRGnFAD6nwtXpSuICmYiNv4lPkS3Jqstd6Hv8AZ74aYcW9n6WlKesQ9VRiKg/PD0Ygji3+lY/E hQx2pWpP82/wrhDGSlcNHIBSpFKnJRFNeQgqYThT+YioX28clbXVKLOH5MSeQ3r45KmPN1V6p/eL v7YUrnA5mUktXfcU3yI7lPNSHp+oD0ruQMlvSC3Gg4gCgruT44kqrxxtQP8Asg7ZAlkInmmFqX5F z1px+/KZObhvmUXFvIqv8QO4plZckeaqQRQUoo7V6UOBscCA9QOtT94oMVcXCuRQBegp7d8UXS1z yI4t4AD/AFjtXCGJNtSI3wqOXGu9duuIRK14AMSnvQ1rg6sxuFrODEwA+yBsPD9rCEE7LP2aAnj2 +dNhhQ2HYAlTQdKDtXGltZKvw0U14GpPucIYTG238KxHIDxgbtRqnw9sSGMTzDZDMOprUnxpQ4pI JcCjsAG3ruabe+KbB5NgozHkKnb5cT1pgTYJXMC45FeBoaUwBJF/0Vi/CN/hIFdu4OEoGwbCqGNT RVA+VP8AM4UUAW2dXXsDWtPCmCkkgtEksF6ITsfBt8V6/wBFqlGAqeRPQ+2FjW624Pw0r8gPbrhi xzHZdEVVNqjkKk4DzZQoBetZFqHG9VAp7YGQNjm0xDLQ7AHsPalMVPJpSRyYbkda4UDqqRKWZRUF TXb54CyjzXfESpX9iqoD88iypfxLBlA+wRsMWTfFVqSadKg9enTAkLQKqwXr1IOFi4MFAIX3p7jx xXkvIY0FNtifkTgTbcjiPaQ1HUBetD4UxAUmlCSaR2Hop6fUBmFMkAGsyJ5NRAK7SEksdmbvhO4T Eb2//9XpIYBDzPxVJ4nv/LTLnBB72xGGCBqniK7/ADrRRjaeDla2pBFAPiJ4gHf/ACsKLcGLKWAK lgWqOvXGkcVheEd6EfY6qeh22wMwCXAMKLXpupP7Q98KACNlrB6htlAFSD3OLEg816/so1Ksalqb dPhwMg3GK1DVAB4t8xv8OJZR3aYBnB5cf2mp1ocQxIs82gBy4oa8aMviTWv/AAuFFdFrGRyEIpT7 LdK/PEIJJ2bLhfh7mi0HjX7bY0vFTlNGCupqfsv06HwxSDvRcysacRyVa8j03riCsgXKh5lpB8JG zVIAb6MSVETdlSeoIfc1BRvl07ZINR7/APMdL9tQDuVqD8sRyTPnQWSOxQlqUXpTrXCA1ykSHVLS AdBUhO1a/LFbsqjt6caxr9kEnl41/wCbsiObbI1GghnVgFRup6nuCNqZMONIGgC6rEKAeJ2Jbw2w qLUyyvKSFpvvXv74aoNZIMm2rOFCqOSVJboQKfZH/A48mVmewWhKBXc/E32AfGtMbXg5EqJDBzQV oQCa9vbJtVbrJQORUivYU8e+EMac8f7ziDsRUn2GIOykbtOTXiCSK1p2whWuAblX+82409uoxtCr EEKKOjA9PGuRN2yjRCrEpIEaKWZjQDIlsiL2CLgB4/rOVycnDyRcYcCu1QencbZWXJFrwaIp67Vr 9OBlezdFVNjUEGnzU7YVug2ArEKF3FQPn0wJ2WlYwanpsD2O/bCxIC5mP7RJCmgHbbpgCS5PhJAN eQ3HgD1wlMVPkFpT7Q2/HCxJptYzyPMELXeniTgJUBv4fsjYVox+RxS09KOK0p+IpU4UHqoyBFVX HWta+IwjdrkABbZYRrwDVDbHxp1xq0kiOzSx0JJ/aP0Y2iMWkqwYgbr4+GJWJtzyMJXIU+1etDjS mW6rxPEc/hodvfvgbBy3adQzEN03qB4YgolG+bQREIBPJzyqDt1HX8cSbYiNOKUBWnwA1U1642kD p0cVFIzX2p3964prk5oxIfi2rsPamN0xMLcgKKQD+7b4SO++JSBQ/otxKwoQeQevGg7VpXElYAhc VVUPIljtSnjgZEUFpo3+x+I06nfp+OFBXRKVKsdwN3HvXErEEK53oqU61A7GnTINiwtwGxoWFaDr v1whBNL1Gxr8QNK9z/ntgS2vxB2A3+yAfDEoaYRRH42rXovWuO5TyUzeF6iMemKbkjeuHhYCYPJY sbofgYHl+140/wCNskSiIIVCzE/F9kE9eoyLY1VODFAabD5nvivuf//W6Yftmm8aHmSfn0y5w+vk 5i7l25UZj8NOtP5cVom1ipGDvUGgK033/wBbDaBEOIBkPGpptQ9q9sRyQR6tm4VA+FdgBRQaUxKw FLjJyBYEk04ivQAD4sFMr2sKRYn4iKgAElt9h2GSpqJVZRQBjs+xFd6A9BgDZLlapD9hSdwtSQDv T+b/AGORLKPJTpyDO2z03r1worr1arShUV3p77YVtsklAXNdqL4/LFHTdriqih3oVb4tifbAigHE xmUlAQT0A7da49EirduCUboe426f24r5LPV3K1pH0Wp39zhpjx/6VSCrRj1G4APXock1CIWfshmF QAaV98LDzLaIUZSxorDfavX/ACcNrGNV/SVZDxiqq0ZQVDHrRj9rIjm2y2ioyKnpGpPwpzB8D04t khza5AV/m8TiEKUSpPEEgncUGDqpAI2WlgoKrUIaVr9r/Kwtd1y5LJVG5iU0ptT3OSB72Ex/NbUL 6yoKrGVPN/Bh9vB0bIgX5KLSNKzKNxTrToB/LkqpplMyWpxozPyIFCQP4YUCuqkCxPJR2IAPYDvk muyqlAFIJ3rt40pkbZyFBRX7fjU7ntQZPowHNsENJQbAgb++DomrVIoShoNwuxyJlaRAhWAaKbjU jwHzyPMNoBjKkREwLU3Fdqe+QLfjO6Mj5gsK/FtuP1NlZcsBUerE77V+z4AYEkLkg5MAuxG9T+AG PEvCv9KimhAI679TXBbJb6bcRxX4QalsNorZv0m4hQK8hUntU4rS3g7AMq9AOv3Y2tNNAvw+o6qR tyrvthtBA6tyKrhRG4ag61wDZTRWUPA8RUr1GSRyDiiUrJIq+KA1oSOmBdurbiKUUEi1psTsAfDA EyohRWJ3YAgMVIGxr365O6agL5ttA4Kg15HqOwp74LZcK0KSKioI6HtTEopoBiWZ9q7E4UAdSqcK CorQU2+eBspUrVgp7137/LIsmpSATxU8h8O/XjTEMZLQSeNSKsOg7MO2+SUFbzJcErvTr7/zY0i9 3KtH4E1Unv4HbE8kAUaXFVEjKB8P2QAd9z3wdE9W1FFTi22/T9nfFIC5lYhQqlhQgGvenw/qwBTb vq8ikkbLx3r1r144eJHCbW/uo1o8q9NwNzWvTDumwBzVI3Dkqg6j7THfpkSEg2tZV4oJHVeFd+5P ffEIl0tsyRBh6ZLciaeGNMrCw3MjEcaJGQaFRVvDDwsOIn+qtWNQ5oOQ6iu564bSIi1zFeW5FKVI 74AppcifByUbgVI79cSmIa5Fk7cqCu/7OKncNqy8eKgigo/uO2BQ/wD/1+mOy8eVaVWhFOw2GXAO IZClmyrvtRCQe+3Q4WF0P810T0AJ3PI1r0rTEhYyWyA1j7KTUnxp1whjLo2TJ6IC0HWhPWhwdUG+ HZ0aEDbqANj3ru2ElMY0vkCMpC0VaAHfuf2siGcqIpbtuei9APbxwsQqhkrxHUbfMdaD54GywpEb ooIFS2/bZsLX3LgCh5Ddj1Fdh8sUjZtRTjy3qTX5YCzi28gMtTuD36032GICDLdTQuprxo1d69eu EsYktuBK44KPSHTelTvyriNkEWf6KlL8JKLTenap37ZINc9tg4kFSVWrE060IxTdjYLfiHwDcjah 6UGFjuNl4dCOtF6VIqTToMFMhIFYy8owTUu/Qdioqvw/6mFgdx5yU7gqOSxiqClQd9x3wxa8hHIc nID9kmu7UUfLEsonotKqrBkavwgFT8qYWMgBuGlVACrD4yPhPfkD1xtiABz+ppuISjCjOCSQakkG n/DYQiVcP9ZYjS+kUi2qCGO1aHr1wmr3REnhoLVCkrGxA5VHI+52LYsI1yUwDyp9AYeGSYdV1WmZ ia/Ew5E9djg5M7MitChJ2atamoqOv0dsN2GI2kSuMar3qPxwWk0CvQklKAMa1bxJwFIJJC8s7cQB utfiHXc+OBmZE1X8KLjVfTDOArsaE134jvTKy5Uaqz9SJWVCdlJJ6EmgyJDeJ3yVFlmNSigU7gV9 u+RpkCS0WlfdmP8AqjbFVLgzHbYk0oMkxpsw8aDkRyHw0J3ONsTGl6q6qAHdW3HXbbEs6cPW5nm7 FANgT+vBsoBtSmAJ41oOtPYjJBjLdTZTwSmwHgO3viwN0KcYnUClakHYk9T3GEFiYFoKYzzAqAN6 4btABjuvMfIcl32/4lkbZmN7qLxrGKh2DbcaGnXvtkwbaZw4eqtxuFjB9Vg7dF6gU27+2Q2bQJVz 9TlkuuJQNWhANQCcaCQZO9S55H41Ip/KNz2OGgty73JPKCwdAzAbdvvxMQsZne1XnIOASNS/KhrU ihpvkKDORkKoLWndm3jUvXiSNt/n8sPCjjPc4z+mCDCBwNSK1ONWvHXR0M8e4KMDU06GncYkJhMK qNG7OOSqx23+VciWzYuV4VPL1k5HsSK40WPFHvbMsKfEayCnLig+jGkykAp/WWegH7qM0BK7np45 Lhph4lrZVDqp5khtqVO1O+IKyFteihKqqioodiKnDaDAdHGPivw05U2HfrXfBa8NcnNDEVq43qSB v4/1xBKmAPNUISOqIeIqHJI7UwM6AWmJ46MFBSvwge2+G2NUqRGNRvtyB69siWwVTRDMeQ7gArTv TfCCxNrlj6g1JI3HhU+OAllFaxXkOCmh2K4QgloAL7kihwLT/9k= --=_NextPart_2rfkindysadvnqw3nerasdf--