From mailman-admin@ietf.org Sun Jun 1 11:34:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16960 for ; Sun, 1 Jun 2003 11:34:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51FXsB29392 for ; Sun, 1 Jun 2003 11:33:54 -0400 Date: Sun, 01 Jun 2003 11:33:54 -0400 Message-ID: <20030601153354.11734.2796.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, dhcwg-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 All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Thu Jun 5 05:25:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12422; Thu, 5 Jun 2003 05:25:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h559P0B16888; Thu, 5 Jun 2003 05:25:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h559LeB16757 for ; Thu, 5 Jun 2003 05:21:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12357 for ; Thu, 5 Jun 2003 05:21:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NquP-0004RN-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 05:19:45 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19NquO-0004RK-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 05:19:44 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h559L1VI006474; Thu, 5 Jun 2003 11:21:02 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 03560A78F2; Thu, 5 Jun 2003 11:08:51 +0200 (CEST) Message-ID: <3EDF0AE3.4070201@ccrle.nec.de> Date: Thu, 05 Jun 2003 11:18:27 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org References: <3EC9F979.0@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Interop Event after IETF-57 in Vienna/DHCPv6.org Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, as announced in the attached email, the DHCPv6 interop event takes place in Vienna during July. Please take a look on http://www.dhcpv6.org/ in the events section for further information about the interop. The events section will be updated with a test case document within the next few days. This dhcpv6.org website presents further information about DHCPv6 and its application. If you have any information, like available software, that may be interesting to other people you can send a link and we will put it on the web page. With best regards Martin Martin Stiemerling wrote: > Hi, > > I'm happy to announce the DHCPv6 Interop Event at the IETF-57 in Vienna. > > This DHCPv6 Interop is sponsored by NEC Network Laboratories Europe and > will be held in Vienna right after the IETF-57 meeting from July 18th to > July 19th. The location will be at the same place as the IETF or next > to the IETF venue. > > Further information about the exact location, time, environment and > tests will be available within the next week on this web page and will > be announced separately: http://www.dhcpv6.org/ > > Regards > Martin > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 5 19:41:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22403; Thu, 5 Jun 2003 19:41:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55NeMB22124; Thu, 5 Jun 2003 19:40:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55NbAB21252 for ; Thu, 5 Jun 2003 19:37:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22327 for ; Thu, 5 Jun 2003 19:37:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O4GK-0004br-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 19:35:16 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19O4GJ-0004bn-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 19:35:15 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h55NaW51016097; Thu, 5 Jun 2003 19:36:32 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-278.cisco.com [10.21.97.22]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id TAA24343; Thu, 5 Jun 2003 19:36:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20030605193018.03da2318@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 19:36:24 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The following drafts have passed WG last call: [1] A DNS RR for Encoding DHCP Information (DHCID RR) [2] The DHCP Client FQDN Option [3] Resolution of DNS Name Conflicts Among DHCP Clients Several issues regarding these drafts have been identified during the AD review prior to IESG review for Proposed Standard status. I will initiate discussion threads on each of these issues later today with e-mail to both the dhcwg and namedroppers mailing lists. Please respond just to the dhcwg mailing list to avoid duplicate postings... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 5 19:45:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22518; Thu, 5 Jun 2003 19:45:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55NilB22524; Thu, 5 Jun 2003 19:44:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55NgQB22230 for ; Thu, 5 Jun 2003 19:42:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22459 for ; Thu, 5 Jun 2003 19:42:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O4LP-0004eO-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 19:40:32 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19O4LO-0004eF-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 19:40:30 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h55Nfk51016956; Thu, 5 Jun 2003 19:41:47 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-278.cisco.com [10.21.97.22]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id TAA24637; Thu, 5 Jun 2003 19:41:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20030605193716.03d40c28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 19:41:37 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Ralph Droms , Thomas Narten , Erik.Nordmark@eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] DDNS-DHCP [1]: Use DHCID RR just for DHCP or extend for other update mechanisms? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DDNS-DHCP issue: The DHCID RR represents an advisory lock used by entities using DHCP to resolve conflicts in the use of DNS records. Is it limiting to restrict the RR to use by entities using DHCP, because there might be other scenarios in the future that could use the same advisory lock mechanism? Or, should the DHCID RR be reserved for use in conjunction with DHCP? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 5 22:26:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25744; Thu, 5 Jun 2003 22:26:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562QAB32595; Thu, 5 Jun 2003 22:26:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562NiB32530 for ; Thu, 5 Jun 2003 22:23:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25694 for ; Thu, 5 Jun 2003 22:23:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O6rS-0005T6-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 22:21:47 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19O6rS-0005St-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 22:21:46 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h562Mtpi018070; Thu, 5 Jun 2003 22:22:55 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-278.cisco.com [10.21.97.22]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id WAA03181; Thu, 5 Jun 2003 22:22:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20030605221922.00bbc948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 22:22:44 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Ralph Droms , Thomas Narten , Erik.Nordmark@eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] DDNS-DHCP [2]: Allow for other identifying data in the DHCID RR? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DDNS-DHCP issue: The DHCID RR data consists of a type code and a hash of the identifier of the updater of the record. Should it be generalized (perhaps as a side effect of generalizing the use of the DHCID RR to other types of resolution) to a type code and type-specific data? That is, should the DHCID RR allow for other forms of data in addition to a 16-byte MD5 hash value to be stored with the type code? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 5 23:15:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26626; Thu, 5 Jun 2003 23:15:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h563EXB03757; Thu, 5 Jun 2003 23:14:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h563BxB03655 for ; Thu, 5 Jun 2003 23:11:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26577 for ; Thu, 5 Jun 2003 23:11:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O7c9-0005jD-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 23:10:01 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19O7c8-0005is-00 for dhcwg@ietf.org; Thu, 05 Jun 2003 23:10:00 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h563BMLV016824 for ; Thu, 5 Jun 2003 23:11:22 -0400 (EDT) Date: Thu, 5 Jun 2003 23:11:22 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-failover-12 (2nd last call) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Because of the limited response to the first WG last call on "DHCP Failover Protocol" (I received one private response and there were no responses on the WG mailing list), there will be a second last call. The last call will conclude on Monday, July 7. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of response to the WG last call will be interpreted as an indication that the document should not be submitted to the IESG for review. draft-ietf-dhc-failover-12.txt defines a protocol to provide synchronization between two DHCP servers. The DHCP specification [RFC 2131] allows for multiple servers to be operating on a single network. For a deployment with multiple servers to work reliably, cooperating primary and secondary servers must be synchronized to maintain a consistent database of the lease information. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-12.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 00:13:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27708; Fri, 6 Jun 2003 00:13:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h564DJB07531; Fri, 6 Jun 2003 00:13:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h564ASB07471 for ; Fri, 6 Jun 2003 00:10:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27663 for ; Fri, 6 Jun 2003 00:10:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O8Wn-0005z0-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 00:08:33 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19O8Wm-0005yu-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 00:08:32 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5649qLV024405 for ; Fri, 6 Jun 2003 00:09:52 -0400 (EDT) Date: Fri, 6 Jun 2003 00:09:54 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] WG last call on draft-ietf-dhc-server-mib-08 (2nd last call) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Because of the limited response to the first WG last call on "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB" (I received one private response and there were no responses on the WG mailing list), there will be a second last call. The last call will conclude on Friday, May 9. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of response to the WG last call will be interpreted as an indication that the document should not be submitted to the IESG for review. draft-ietf-dhc-server-mib-08.txt defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol for IPv4 (DHCPv4) and Bootstrap Protocol (BOOTP) servers. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-08.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 00:33:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28262; Fri, 6 Jun 2003 00:33:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h564X3B08261; Fri, 6 Jun 2003 00:33:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h564TTB08123 for ; Fri, 6 Jun 2003 00:29:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28182 for ; Fri, 6 Jun 2003 00:29:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O8pB-00065z-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 00:27:33 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19O8pA-00065S-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 00:27:32 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h564S5LU026537; Fri, 6 Jun 2003 00:28:06 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-278.cisco.com [10.21.97.22]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id AAA13932; Fri, 6 Jun 2003 00:28:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606002703.03d40c28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 00:27:56 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Ralph Droms , Thomas Narten , Erik.Nordmark@eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DDNS-DHCP issue: The interaction between DHCPv4 and DHCPv6 needs to be carefully defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 server updates the AAAA RR of the same node? How is the conflict in the use of the DHCID RR for that node resolved? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 01:25:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29237; Fri, 6 Jun 2003 01:25:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h565P0B11334; Fri, 6 Jun 2003 01:25:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h565KFB11233 for ; Fri, 6 Jun 2003 01:20:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29112 for ; Fri, 6 Jun 2003 01:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O9cI-0006IX-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 01:18:18 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19O9cH-0006IT-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 01:18:17 -0400 Received: from tsundru.dmes.org (az-ben-pm3-2-33.ppp.theriver.com [206.25.50.33]) by toccata.fugue.com (Postfix) with ESMTP id 05B731B2003; Thu, 5 Jun 2003 23:15:04 -0500 (CDT) From: Ted Lemon Date: Thu, 5 Jun 2003 22:19:57 -0700 User-Agent: KMail/1.5 To: dhcwg@ietf.org, namedroppers@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306052219.57646.mellon@nominum.com> Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: DDNS-DHCP [2]: Allow for other identifying data in the DHCID RR? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Issues one and two are basically the same issue - should we extend DHCID to make it work for things other than DHCP. The answer is, flatly, no. This would be a disaster. The reason is that DHCID specifies a DHCP-specific format for the hash. If you aren't doing DHCP, you don't have enough information to create a hash that interoperates. Discussion point one says "shouldn't we do this?" The answer is no. Discussion point two says "here's how we should do this." The problem is that if you have other applications using the DHCID with different information, then DHCID's intended use is broken - the DHCP server can't use DHCID records it's inserted if some other thing is also inserting records, because the DHCP server depends on the DHCID working correctly in update prerequisites. So either option 1 or option 2 breaks interoperability, and can't be allowed. If some other application needs to do something similar to DHCID (I can't think of any reason why one would, but stipulating that one would), it could just define a new RRtype. There is no shortage of RRtype codes. Adding complexity to DHCID to support theoretical new protocols we haven't even designed yet is a false economy - it breaks the DHCP/DNS interaction model, and it does not add value. It is a solution in search of a problem. Simple Is Good. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 02:22:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11722; Fri, 6 Jun 2003 02:22:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566LqB25724; Fri, 6 Jun 2003 02:21:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566H7B25038 for ; Fri, 6 Jun 2003 02:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11423 for ; Fri, 6 Jun 2003 02:17:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OAVJ-0006Vw-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 02:15:09 -0400 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 19OAUx-0006Vt-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 02:15:08 -0400 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h566GJ227631 for ; Fri, 6 Jun 2003 13:16:25 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h566G8q09447 for ; Fri, 6 Jun 2003 13:16:09 +0700 (ICT) From: Robert Elz To: dhcwg@ietf.org Subject: Re: [dhcwg] Re: DDNS-DHCP [2]: Allow for other identifying data in the DHCID RR? In-Reply-To: <200306052219.57646.mellon@nominum.com> References: <200306052219.57646.mellon@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Jun 2003 13:16:08 +0700 Message-ID: <8298.1054880168@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Thu, 5 Jun 2003 22:19:57 -0700 From: Ted Lemon Message-ID: <200306052219.57646.mellon@nominum.com> | Issues one and two are basically the same issue - should we extend DHCID to | make it work for things other than DHCP. The answer is, flatly, no. This | would be a disaster. Agreed. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 06:26:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16370; Fri, 6 Jun 2003 06:26:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AQRB10216; Fri, 6 Jun 2003 06:26:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56ALMB10111 for ; Fri, 6 Jun 2003 06:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16246 for ; Fri, 6 Jun 2003 06:21:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OEJg-0000FY-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 06:19:24 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19OEJf-0000EM-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 06:19:23 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56AKgLV008095; Fri, 6 Jun 2003 06:20:43 -0400 (EDT) Date: Fri, 6 Jun 2003 06:20:42 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org, namedroppers@ops.ietf.org cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DDNS-DHCP [3]: 12 bit RCODEs in DHCP FQDN option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DDNS-DHCP issue: The DHCP FQDN option should carry 12 bit RCODEs, for consistency with the extended RCODEs defined by EDNS0. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 06:59:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17320; Fri, 6 Jun 2003 06:59:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AwlB12238; Fri, 6 Jun 2003 06:58:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AslB12116 for ; Fri, 6 Jun 2003 06:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17164 for ; Fri, 6 Jun 2003 06:54:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OEq0-0000VZ-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 06:52:48 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19OEpz-0000VW-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 06:52:47 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56ArvLV012084; Fri, 6 Jun 2003 06:53:58 -0400 (EDT) Date: Fri, 6 Jun 2003 06:53:57 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org, namedroppers@ops.ietf.org cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DDNS-DHCP [4]: 12 bit RCODEs in DHCP FQDN option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DDNS-DHCP issue: The DHCP FQDN option should carry 12 bit RCODEs, for consistency with the extended RCODEs defined by EDNS0. (reposted with corrected issue number...) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 07:06:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17586; Fri, 6 Jun 2003 07:06:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56B5gB12548; Fri, 6 Jun 2003 07:05:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56B1nB12412 for ; Fri, 6 Jun 2003 07:01:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17462 for ; Fri, 6 Jun 2003 07:01:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OEwo-0000Zi-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 06:59:50 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19OEwn-0000Zf-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 06:59:49 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56B13LV013829; Fri, 6 Jun 2003 07:01:04 -0400 (EDT) Date: Fri, 6 Jun 2003 07:01:03 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org, namedroppers@ops.ietf.org cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DDNS-DHCP [5]: IDN in DDNS-DHCP docs Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DDNS-DHCP issue: The IDN WG has concluded and the results of its work should be considered in the DDNS-DHCP documents. The changes may be as minimal as specifying the use of the IDN on-the-wire format. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 10:43:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26478; Fri, 6 Jun 2003 10:43:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Eh4B29533; Fri, 6 Jun 2003 10:43:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EaCB28332 for ; Fri, 6 Jun 2003 10:36:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26231 for ; Fri, 6 Jun 2003 10:36:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIIH-0002aH-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 10:34:13 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19OIIG-0002a9-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 10:34:12 -0400 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56EZYLV029159; Fri, 6 Jun 2003 10:35:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606102532.01d4ef98@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 10:35:34 -0400 To: Ted Lemon From: Mark Stapp Subject: Re: [dhcwg] Re: DDNS-DHCP [2]: Allow for other identifying data in the DHCID RR? Cc: dhcwg@ietf.org, namedroppers@ietf.org In-Reply-To: <200306052219.57646.mellon@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thank you Ted - that's an excellent response. We're trying to solve a specific problem, a problem we believe we understand. We took some steps towards generalizing the rr, in that we made the type codes within the rr data an iana-managed space, and described what it would take for someone to have a new code allocated. That's really all the generality that's justified by the experience we have right now. -- Mark At 10:19 PM 6/5/2003 -0700, Ted Lemon wrote: >Issues one and two are basically the same issue - should we extend DHCID to >make it work for things other than DHCP. The answer is, flatly, no. This >would be a disaster. > >The reason is that DHCID specifies a DHCP-specific format for the hash. If >you aren't doing DHCP, you don't have enough information to create a hash >that interoperates. Discussion point one says "shouldn't we do this?" The >answer is no. > >Discussion point two says "here's how we should do this." The problem is >that if you have other applications using the DHCID with different >information, then DHCID's intended use is broken - the DHCP server can't use >DHCID records it's inserted if some other thing is also inserting records, >because the DHCP server depends on the DHCID working correctly in update >prerequisites. > >So either option 1 or option 2 breaks interoperability, and can't be allowed. > >If some other application needs to do something similar to DHCID (I can't >think of any reason why one would, but stipulating that one would), it could >just define a new RRtype. There is no shortage of RRtype codes. > >Adding complexity to DHCID to support theoretical new protocols we haven't >even designed yet is a false economy - it breaks the DHCP/DNS interaction >model, and it does not add value. It is a solution in search of a problem. > >Simple Is Good. > >_______________________________________________ >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-admin@ietf.org Fri Jun 6 10:55:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26995; Fri, 6 Jun 2003 10:55:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EsqB30111; Fri, 6 Jun 2003 10:54:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EoYB29930 for ; Fri, 6 Jun 2003 10:50:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26782 for ; Fri, 6 Jun 2003 10:50:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIWB-0002i9-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 10:48:35 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19OIWA-0002hx-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 10:48:34 -0400 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56EnrLV003594; Fri, 6 Jun 2003 10:49:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606103540.01d4e9d0@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 10:49:52 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] DDNS-DHCP [4]: 12 bit RCODEs in DHCP FQDN option Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org, olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This issue was raised once before. There's some history here, so I'll try to summarize it briefly. The format of the dhcp fqdn option has been around for a long time. It was used in the implementation of some dhcp clients. There are very many of those clients, and they really expect that there are two bytes of data in those RCODE positions. The only RCODEs that are part of the dhcp/dns specs fix in 8 bits. We reached consensus on the mailing list that it was more important to maintain support for the millions of deployed clients than it was to change the physical format of the dhcp option for this purpose. I recorded this decision in section 4.2 of the fqdn option draft. -- Mark At 06:53 AM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The DHCP FQDN option should carry 12 bit RCODEs, for > consistency with the extended RCODEs defined by EDNS0. > > >(reposted with corrected issue number...) >_______________________________________________ >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-admin@ietf.org Fri Jun 6 14:37:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06684; Fri, 6 Jun 2003 14:37:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56IaqB18221; Fri, 6 Jun 2003 14:36:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56IW6B18049 for ; Fri, 6 Jun 2003 14:32:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06453 for ; Fri, 6 Jun 2003 14:32:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OLyX-0005Em-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 14:30:05 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 19OLyV-0005EF-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 14:30:04 -0400 Received: from [207.102.214.106] (helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 19OLzQ-0007nB-00; Fri, 06 Jun 2003 11:31:00 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 11:31:26 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> From: "Cosmo, Patrick" To: "'Ralph Droms'" , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction drafts Date: Fri, 6 Jun 2003 11:31:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C59.D6969490" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C32C59.D6969490 Content-Type: text/plain; charset="iso-8859-1" I have found some minor issues with the , I apologize if they have already been brought up. In particular, this statement in section 5. (DNS RR TTLs) on page 5: "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at least 10 minutes." 1. This sentence has some bad grammar ("for with" : ... record added for with a DHCP lease ...). 2. The statement is contradictory if the lease time is less than 30 minutes. When the lease time is less than 30 minutes, which suggestion takes precendence? : min. 10 minutes, or max or 1/3 lease time? 3. The section seems intended to suggest a reasonable TTL for these records, but doesn't seem to pull through or suggest much of anything (IMHO) other than "it should be a function of lease time, and it should be configurable". Patrick Cosmo Senior Product Engineer Incognito Software Inc Vancouver: (604) 688-4332 ext: 254 Toll-Free: 1-800-877-1856 http://www.incognito.com -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, June 05, 2003 7:36 PM To: dhcwg@ietf.org; namedroppers@ops.ietf.org Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts The following drafts have passed WG last call: [1] A DNS RR for Encoding DHCP Information (DHCID RR) [2] The DHCP Client FQDN Option [3] Resolution of DNS Name Conflicts Among DHCP Clients Several issues regarding these drafts have been identified during the AD review prior to IESG review for Proposed Standard status. I will initiate discussion threads on each of these issues later today with e-mail to both the dhcwg and namedroppers mailing lists. Please respond just to the dhcwg mailing list to avoid duplicate postings... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C32C59.D6969490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Issues in DDNS-DHCP interaction drafts

I have found some minor issues with the = <draft-ietf-dhc-ddns-resolution-05.txt>, I apologize if they have = already been brought up.

In particular, this statement in section 5. (DNS RR = TTLs) on page 5:

"The RR TTL on a DNS record added for with a = DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at = least 10 minutes."

1. This sentence has some bad grammar ("for = with" : ... record added for with a DHCP lease ...).

2. The statement is contradictory if the lease time = is less than 30 minutes. When the lease time is less than 30 minutes, = which suggestion takes precendence? : min. 10 minutes, or max or 1/3 = lease time?

3. The section seems intended to suggest a reasonable = TTL for these records, but doesn't seem to pull through or suggest much = of anything (IMHO) other than "it should be a function of lease = time, and it should be configurable".

Patrick Cosmo
 
Senior Product Engineer
Incognito Software Inc
Vancouver: (604) 688-4332 ext: 254
Toll-Free: 1-800-877-1856
http://www.incognito.com
 


-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, June 05, 2003 7:36 PM
To: dhcwg@ietf.org; namedroppers@ops.ietf.org
Subject: [dhcwg] Issues in DDNS-DHCP interaction = drafts


The following drafts have passed WG last call:

[1] A DNS RR for Encoding DHCP Information (DHCID = RR)
    = <draft-ietf-dnsext-dhcid-rr-06.txt>

[2] The DHCP Client FQDN Option
    = <draft-ietf-dhc-fqdn-option-05.txt>

[3] Resolution of DNS Name Conflicts Among DHCP = Clients
    = <draft-ietf-dhc-ddns-resolution-05.txt>

Several issues regarding these drafts have been = identified
during the AD review prior to IESG review for = Proposed
Standard status.  I will initiate discussion = threads on
each of these issues later today with e-mail to = both
the dhcwg and namedroppers mailing lists.  = Please respond
just to the dhcwg mailing list to avoid duplicate = postings...

- Ralph

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

------_=_NextPart_001_01C32C59.D6969490-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 15:07:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07981; Fri, 6 Jun 2003 15:07:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J6eB20453; Fri, 6 Jun 2003 15:06:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56IVhB18017 for ; Fri, 6 Jun 2003 14:31:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06441 for ; Fri, 6 Jun 2003 14:31:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OLyA-0005EY-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 14:29:42 -0400 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by ietf-mx with esmtp (Exim 4.12) id 19OLy8-0005EE-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 14:29:40 -0400 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h56IVMH05214 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 6 Jun 2003 14:31:22 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h56IVLg3008075; Fri, 6 Jun 2003 14:31:21 -0400 Message-Id: <200306061831.h56IVLg3008075@sandelman.ottawa.on.ca> To: dhcwg@ietf.org, namedroppers@ops.ietf.org In-reply-to: Your message of "Thu, 05 Jun 2003 19:41:37 EDT." <4.3.2.7.2.20030605193716.03d40c28@funnel.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Jun 2003 14:31:20 -0400 From: Michael Richardson Subject: [dhcwg] Re: DDNS-DHCP [1]: Use DHCID RR just for DHCP or extend for other update mechanisms? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Well, trivially, I can see that a PPP end point might want to use dynamic update for the same reason that DHCP might. (And PPPoE is very popular now). So, I'd say that anything that needs to *interlock* with DHCP needs to use it. But, maybe I misunderstood the question. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPuDd94qHRg3pndX9AQHNiwP9GSWc2inQiw2kL4ClDaTgyKzyXxT38/QE 4guuwTUqo5Se9IEqAK/gr1lwN84ZlyzEleNJaX87dUeWq3BY/Gk7B1UziiLTsVor dbAeWS7lYuKnkTBrDF7pu49hDJ/GAcqnjBK2uwRfSrfHdmTacatvDqB1JwjJY26x QC7k8HeIqfc= =oBMX -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 15:15:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08937; Fri, 6 Jun 2003 15:15:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56JEvB21702; Fri, 6 Jun 2003 15:14:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56JCEB21621 for ; Fri, 6 Jun 2003 15:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08546 for ; Fri, 6 Jun 2003 15:12:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OMbQ-0005Yr-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 15:10:16 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19OMbP-0005Yb-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 15:10:15 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56JBZLV019333; Fri, 6 Jun 2003 15:11:35 -0400 (EDT) Date: Fri, 6 Jun 2003 15:11:35 -0400 (EDT) From: Ralph Droms To: namedroppers@ops.ietf.org, dhcwg@ietf.org cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> Message-ID: References: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DDNS-DHCP issue: The RR TTLs need careful attention so that it never exceeds the expiration time of the lease on the associated address. This issue was anticipated by Patrick Cosmo: On Fri, 6 Jun 2003, Cosmo, Patrick wrote: > I have found some minor issues with the > , I apologize if they have already > been brought up. > > In particular, this statement in section 5. (DNS RR TTLs) on page 5: > > "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed > 1/3 of the lease time, and SHOULD be at least 10 minutes." > > 1. This sentence has some bad grammar ("for with" : ... record added for > with a DHCP lease ...). > > 2. The statement is contradictory if the lease time is less than 30 minutes. > When the lease time is less than 30 minutes, which suggestion takes > precendence? : min. 10 minutes, or max or 1/3 lease time? > > 3. The section seems intended to suggest a reasonable TTL for these records, > but doesn't seem to pull through or suggest much of anything (IMHO) other > than "it should be a function of lease time, and it should be configurable". > > > Patrick Cosmo > > Senior Product Engineer > Incognito Software Inc > Vancouver: (604) 688-4332 ext: 254 > Toll-Free: 1-800-877-1856 > http://www.incognito.com > > > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, June 05, 2003 7:36 PM > To: dhcwg@ietf.org; namedroppers@ops.ietf.org > Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > > > The following drafts have passed WG last call: > > [1] A DNS RR for Encoding DHCP Information (DHCID RR) > > > [2] The DHCP Client FQDN Option > > > [3] Resolution of DNS Name Conflicts Among DHCP Clients > > > Several issues regarding these drafts have been identified > during the AD review prior to IESG review for Proposed > Standard status. I will initiate discussion threads on > each of these issues later today with e-mail to both > the dhcwg and namedroppers mailing lists. Please respond > just to the dhcwg mailing list to avoid duplicate postings... > > - Ralph > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 15:32:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09458; Fri, 6 Jun 2003 15:32:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56JWGB22361; Fri, 6 Jun 2003 15:32:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56JTbB22231 for ; Fri, 6 Jun 2003 15:29:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09372 for ; Fri, 6 Jun 2003 15:29:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OMsG-0005ey-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 15:27:40 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19OMsE-0005et-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 15:27:39 -0400 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56JT0LV023777; Fri, 6 Jun 2003 15:29:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606150043.01d94e48@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 15:28:59 -0400 To: "Cosmo, Patrick" From: Mark Stapp Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction drafts Cc: "'Ralph Droms'" , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.c om.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Patrick, Thanks for the comments. I'll fix the typo. The ttl recommendations resulted from a couple of back-and-forths over a period of years, and the current set of numbers is based on recommendations from the dnsext wg chairs. The basic issue is that dns operators don't want stale rrs lying around after dhcp leases have expired, and at the same time they don't want micro-ttls that make caching ineffective. The core goal was to make implementors aware of the issue, and to recommend common sense when twiddling the configuration. The specific values were meant, I think, to be more concrete guidance, but not a substitute for good sense. As you observe, there's a recommendation, but the specifics are meant to be a guide, and that's why they're 'SHOULD'-strength. The '1/3' number is meant to address the 'stale rrs' concern, and the '10 minutes' is meant to address the 'micro-ttl' concern. Is there something else that could be said in section 5 that would make that clearer? -- Mark At 11:31 AM 6/6/2003 -0700, Cosmo, Patrick wrote: >I have found some minor issues with the >, I apologize if they have already >been brought up. > >In particular, this statement in section 5. (DNS RR TTLs) on page 5: > >"The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed >1/3 of the lease time, and SHOULD be at least 10 minutes." > >1. This sentence has some bad grammar ("for with" : ... record added for >with a DHCP lease ...). > >2. The statement is contradictory if the lease time is less than 30 >minutes. When the lease time is less than 30 minutes, which suggestion >takes precendence? : min. 10 minutes, or max or 1/3 lease time? > >3. The section seems intended to suggest a reasonable TTL for these >records, but doesn't seem to pull through or suggest much of anything >(IMHO) other than "it should be a function of lease time, and it should be >configurable". > >Patrick Cosmo > >Senior Product Engineer >Incognito Software Inc >Vancouver: (604) 688-4332 ext: 254 >Toll-Free: 1-800-877-1856 >http://www.incognito.com > > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, June 05, 2003 7:36 PM >To: dhcwg@ietf.org; namedroppers@ops.ietf.org >Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > >The following drafts have passed WG last call: > >[1] A DNS RR for Encoding DHCP Information (DHCID RR) > > >[2] The DHCP Client FQDN Option > > >[3] Resolution of DNS Name Conflicts Among DHCP Clients > > >Several issues regarding these drafts have been identified >during the AD review prior to IESG review for Proposed >Standard status. I will initiate discussion threads on >each of these issues later today with e-mail to both >the dhcwg and namedroppers mailing lists. Please respond >just to the dhcwg mailing list to avoid duplicate postings... > >- Ralph > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 15:54:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10116; Fri, 6 Jun 2003 15:54:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Js2B24226; Fri, 6 Jun 2003 15:54:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56JnHB24043 for ; Fri, 6 Jun 2003 15:49:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10019 for ; Fri, 6 Jun 2003 15:49:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONBH-0005p2-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 15:47:19 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19ONBG-0005ow-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 15:47:18 -0400 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56JmcLV028649; Fri, 6 Jun 2003 15:48:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606152905.01da4b50@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 15:48:38 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: namedroppers@ops.ietf.org, dhcwg@ietf.org, olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: References: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've replied to Patrick; I'm not quite sure what more to do with issue [6]. The draft recommends using a ttl that's a fraction of the lease time, and recommends removing rrs promptly when the lease expires. There have been at least a couple of exchanges about this over the years, and the conclusion has always been that it's not possible to come up with a single set of values that are appropriate in every situation. Also, it's not possible to compel updaters to perform additional updates to 'back down' rrs' ttls as a lease approaches its expiration - that'll kill the dns server. As I noted in the other email I sent, the recommendations that are in the draft are the most up-to-date ones that I've been offered. We do have quite a bit of deployment experience with dhcp updates to dns, and this has not been an issue, as far as I can recall. I also don't recall any email to the wg indicating that this has been an issue in anyone else's experience. If someone has followed these recommendations and has found problems with them, then by all means let's come up with better recommendations. -- Mark At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The RR TTLs need careful attention so that it never exceeds the > expiration time of the lease on the associated address. > >This issue was anticipated by Patrick Cosmo: > >On Fri, 6 Jun 2003, Cosmo, Patrick wrote: > > > I have found some minor issues with the > > , I apologize if they have already > > been brought up. > > > > In particular, this statement in section 5. (DNS RR TTLs) on page 5: > > > > "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed > > 1/3 of the lease time, and SHOULD be at least 10 minutes." > > > > 1. This sentence has some bad grammar ("for with" : ... record added for > > with a DHCP lease ...). > > > > 2. The statement is contradictory if the lease time is less than 30 > minutes. > > When the lease time is less than 30 minutes, which suggestion takes > > precendence? : min. 10 minutes, or max or 1/3 lease time? > > > > 3. The section seems intended to suggest a reasonable TTL for these > records, > > but doesn't seem to pull through or suggest much of anything (IMHO) other > > than "it should be a function of lease time, and it should be > configurable". > > > > > > Patrick Cosmo > > > > Senior Product Engineer > > Incognito Software Inc > > Vancouver: (604) 688-4332 ext: 254 > > Toll-Free: 1-800-877-1856 > > http://www.incognito.com > > > > > > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Thursday, June 05, 2003 7:36 PM > > To: dhcwg@ietf.org; namedroppers@ops.ietf.org > > Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > > > > > > The following drafts have passed WG last call: > > > > [1] A DNS RR for Encoding DHCP Information (DHCID RR) > > > > > > [2] The DHCP Client FQDN Option > > > > > > [3] Resolution of DNS Name Conflicts Among DHCP Clients > > > > > > Several issues regarding these drafts have been identified > > during the AD review prior to IESG review for Proposed > > Standard status. I will initiate discussion threads on > > each of these issues later today with e-mail to both > > the dhcwg and namedroppers mailing lists. Please respond > > just to the dhcwg mailing list to avoid duplicate postings... > > > > - Ralph > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 6 16:45:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11881; Fri, 6 Jun 2003 16:45:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KisB28556; Fri, 6 Jun 2003 16:44:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KeWB28397 for ; Fri, 6 Jun 2003 16:40:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11753 for ; Fri, 6 Jun 2003 16:40:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONyt-0006Gq-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 16:38:35 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 19ONyr-0006GY-00 for dhcwg@ietf.org; Fri, 06 Jun 2003 16:38:33 -0400 Received: from [207.102.214.106] (helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 19ONzy-00009k-00; Fri, 06 Jun 2003 13:39:42 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 13:40:09 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D19801766941@homer.incognito.com.> From: "Cosmo, Patrick" To: "'Mark Stapp'" Cc: "'Ralph Droms'" , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction drafts Date: Fri, 6 Jun 2003 13:40:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C6B.D18C46E0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C32C6B.D18C46E0 Content-Type: text/plain; charset="iso-8859-1" >Is there something else that could be said >in section 5 that would make that clearer? Is the intention to recommend that the TTL time be 10 minutes or 1/3 of the lease time, whichever is greater? If so: "The RR TTL on a DNS record added for a DHCP lease SHOULD be 1/3 of the lease time or 10 minutes, whichever is greater". Or is the intention to recommend that any time between 10 minutes and 1/3 of the lease time be used for TTL, except when 1/3 of the lease is less than 10 minutes, in which case the TTL should be 10 minutes? If so: "The RR TTL on a DNS record added for a DHCP lease SHOULD NOT exceed 1/3 of the lease time, unless 1/3 of the lease time amounts to less than 10 minutes. The RR TTL on a DNS record added for a DHCP lease SHOULD always be at least 10 minutes." -----Original Message----- From: Mark Stapp [mailto:mjs@cisco.com] Sent: Friday, June 06, 2003 3:29 PM To: Cosmo, Patrick Cc: 'Ralph Droms'; dhcwg@ietf.org; namedroppers@ops.ietf.org Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction drafts Patrick, Thanks for the comments. I'll fix the typo. The ttl recommendations resulted from a couple of back-and-forths over a period of years, and the current set of numbers is based on recommendations from the dnsext wg chairs. The basic issue is that dns operators don't want stale rrs lying around after dhcp leases have expired, and at the same time they don't want micro-ttls that make caching ineffective. The core goal was to make implementors aware of the issue, and to recommend common sense when twiddling the configuration. The specific values were meant, I think, to be more concrete guidance, but not a substitute for good sense. As you observe, there's a recommendation, but the specifics are meant to be a guide, and that's why they're 'SHOULD'-strength. The '1/3' number is meant to address the 'stale rrs' concern, and the '10 minutes' is meant to address the 'micro-ttl' concern. Is there something else that could be said in section 5 that would make that clearer? -- Mark At 11:31 AM 6/6/2003 -0700, Cosmo, Patrick wrote: >I have found some minor issues with the >, I apologize if they have already >been brought up. > >In particular, this statement in section 5. (DNS RR TTLs) on page 5: > >"The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed >1/3 of the lease time, and SHOULD be at least 10 minutes." > >1. This sentence has some bad grammar ("for with" : ... record added for >with a DHCP lease ...). > >2. The statement is contradictory if the lease time is less than 30 >minutes. When the lease time is less than 30 minutes, which suggestion >takes precendence? : min. 10 minutes, or max or 1/3 lease time? > >3. The section seems intended to suggest a reasonable TTL for these >records, but doesn't seem to pull through or suggest much of anything >(IMHO) other than "it should be a function of lease time, and it should be >configurable". > >Patrick Cosmo > >Senior Product Engineer >Incognito Software Inc >Vancouver: (604) 688-4332 ext: 254 >Toll-Free: 1-800-877-1856 >http://www.incognito.com > > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, June 05, 2003 7:36 PM >To: dhcwg@ietf.org; namedroppers@ops.ietf.org >Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > >The following drafts have passed WG last call: > >[1] A DNS RR for Encoding DHCP Information (DHCID RR) > > >[2] The DHCP Client FQDN Option > > >[3] Resolution of DNS Name Conflicts Among DHCP Clients > > >Several issues regarding these drafts have been identified >during the AD review prior to IESG review for Proposed >Standard status. I will initiate discussion threads on >each of these issues later today with e-mail to both >the dhcwg and namedroppers mailing lists. Please respond >just to the dhcwg mailing list to avoid duplicate postings... > >- Ralph > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman /listinfo/dhcwg > ------_=_NextPart_001_01C32C6B.D18C46E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Issues in DDNS-DHCP interaction drafts

>Is there something else that could be said =
>in section 5 that would make that = clearer?

Is the intention to recommend that the TTL time be 10 = minutes or 1/3 of the lease time, whichever is greater? If so:

"The RR TTL on a DNS record added for a DHCP = lease SHOULD be 1/3 of the lease time or 10 minutes, whichever is = greater".

Or is the intention to recommend that any time = between 10 minutes and 1/3 of the lease time be used for TTL, except = when 1/3 of the lease is less than 10 minutes, in which case the TTL = should be 10 minutes? If so:

"The RR TTL on a DNS record added for a DHCP = lease SHOULD NOT exceed
1/3 of the lease time, unless 1/3 of the lease time = amounts to less than 10 minutes. The RR TTL on a DNS record added for a = DHCP lease SHOULD always be at least 10 minutes."


 

-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Friday, June 06, 2003 3:29 PM
To: Cosmo, Patrick
Cc: 'Ralph Droms'; dhcwg@ietf.org; = namedroppers@ops.ietf.org
Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction = drafts


Patrick,
Thanks for the comments. I'll fix the typo.

The ttl recommendations resulted from a couple of = back-and-forths over a
period of years, and the current set of numbers is = based on recommendations
from the dnsext wg chairs. The basic issue is that = dns operators don't want
stale rrs lying around after dhcp leases have = expired, and at the same time
they don't want micro-ttls that make caching = ineffective. The core goal was
to make implementors aware of the issue, and to = recommend common sense when
twiddling the configuration. The specific values = were meant, I think, to be
more concrete guidance, but not a substitute for = good sense. As you
observe, there's a recommendation, but the specifics = are meant to be a
guide, and that's why they're 'SHOULD'-strength. The = '1/3' number is meant
to address the 'stale rrs' concern, and the '10 = minutes' is meant to
address the 'micro-ttl' concern. Is there something = else that could be said
in section 5 that would make that clearer?

-- Mark

At 11:31 AM 6/6/2003 -0700, Cosmo, Patrick = wrote:

>I have found some minor issues with the
><draft-ietf-dhc-ddns-resolution-05.txt>, I = apologize if they have already
>been brought up.
>
>In particular, this statement in section 5. (DNS = RR TTLs) on page 5:
>
>"The RR TTL on a DNS record added for with = a DHCP lease SHOULD NOT exceed
>1/3 of the lease time, and SHOULD be at least 10 = minutes."
>
>1. This sentence has some bad grammar ("for = with" : ... record added for
>with a DHCP lease ...).
>
>2. The statement is contradictory if the lease = time is less than 30
>minutes. When the lease time is less than 30 = minutes, which suggestion
>takes precendence? : min. 10 minutes, or max or = 1/3 lease time?
>
>3. The section seems intended to suggest a = reasonable TTL for these
>records, but doesn't seem to pull through or = suggest much of anything
>(IMHO) other than "it should be a function = of lease time, and it should be
>configurable".
>
>Patrick Cosmo
>
>Senior Product Engineer
>Incognito Software Inc
>Vancouver: (604) 688-4332 ext: 254
>Toll-Free: 1-800-877-1856
><http://www.incognito.com>http://www.incognito.com
>
>
>-----Original Message-----
>From: Ralph Droms [<mailto:rdroms@cisco.com>mailto:rdroms@cisco.com]
>Sent: Thursday, June 05, 2003 7:36 PM
>To: dhcwg@ietf.org; = namedroppers@ops.ietf.org
>Subject: [dhcwg] Issues in DDNS-DHCP interaction = drafts
>
>The following drafts have passed WG last = call:
>
>[1] A DNS RR for Encoding DHCP Information = (DHCID RR)
>     = <draft-ietf-dnsext-dhcid-rr-06.txt>
>
>[2] The DHCP Client FQDN Option
>     = <draft-ietf-dhc-fqdn-option-05.txt>
>
>[3] Resolution of DNS Name Conflicts Among DHCP = Clients
>     = <draft-ietf-dhc-ddns-resolution-05.txt>
>
>Several issues regarding these drafts have been = identified
>during the AD review prior to IESG review for = Proposed
>Standard status.  I will initiate = discussion threads on
>each of these issues later today with e-mail to = both
>the dhcwg and namedroppers mailing lists.  = Please respond
>just to the dhcwg mailing list to avoid = duplicate postings...
>
>- Ralph
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg =
>

------_=_NextPart_001_01C32C6B.D18C46E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 10 07:54:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21943; Tue, 10 Jun 2003 07:54:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABrlB12988; Tue, 10 Jun 2003 07:53:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABoTB12853 for ; Tue, 10 Jun 2003 07:50:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21303; Tue, 10 Jun 2003 07:50:27 -0400 (EDT) Message-Id: <200306101150.HAA21303@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 10 Jun 2003 07:50:27 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : IPv6 Prefix Options for DHCPv6 Author(s) : O. Troan, R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt Pages : 19 Date : 2003-6-9 The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dhcpv6-opt-prefix-delegation-04.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-dhcpv6-opt-prefix-delegation-04.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: <2003-6-9150704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9150704.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 10 07:56:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22098; Tue, 10 Jun 2003 07:56:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABtoB13075; Tue, 10 Jun 2003 07:55:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABoZB12858 for ; Tue, 10 Jun 2003 07:50:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21331; Tue, 10 Jun 2003 07:50:33 -0400 (EDT) Message-Id: <200306101150.HAA21331@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 10 Jun 2003 07:50:33 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-relay-agent-auth-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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, R. Droms Filename : draft-ietf-dhc-relay-agent-auth-01.txt Pages : 16 Date : 2003-6-9 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP relay agent and a DHCP server. This specification defines two mechanisms for securing the messages exchanged between a relay agent and a server. The first mechanism defines a new authentication suboption for the Relay Agent Information Option that supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in a payload derived from the option used in DHCP Authentication (RFC 3118). The second mechanism uses IPsec (RFC 2041) to protect messages exchanged between relay agents and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-auth-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-relay-agent-auth-01.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-relay-agent-auth-01.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: <2003-6-9150737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-relay-agent-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-relay-agent-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9150737.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 10 07:58:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22240; Tue, 10 Jun 2003 07:58:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABvhB13182; Tue, 10 Jun 2003 07:57:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABogB12862 for ; Tue, 10 Jun 2003 07:50:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21347; Tue, 10 Jun 2003 07:50:40 -0400 (EDT) Message-Id: <200306101150.HAA21347@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 10 Jun 2003 07:50:40 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Unused DHCP Option Codes Author(s) : R. Droms Filename : draft-ietf-dhc-unused-optioncodes-03.txt Pages : 9 Date : 2003-6-9 Prior to the publication of RFC2939 (which was updated by RFC2489), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-unused-optioncodes-03.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-unused-optioncodes-03.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: <2003-6-9150753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9150753.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 10 17:22:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18662; Tue, 10 Jun 2003 17:22:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALLRB28444; Tue, 10 Jun 2003 17:21:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALI2B28285 for ; Tue, 10 Jun 2003 17:18:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18429; Tue, 10 Jun 2003 17:17:57 -0400 (EDT) Message-Id: <200306102117.RAA18429@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Tue, 10 Jun 2003 17:17:57 -0400 Subject: [dhcwg] Last Call: IPv6 Prefix Options for DHCPv6 to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration Working Group to consider IPv6 Prefix Options for DHCPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 10 21:34:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25756; Tue, 10 Jun 2003 21:34:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1XRB12051; Tue, 10 Jun 2003 21:33:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1UrB11971 for ; Tue, 10 Jun 2003 21:30:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25692 for ; Tue, 10 Jun 2003 21:30:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PuPu-0003o4-00 for dhcwg@ietf.org; Tue, 10 Jun 2003 21:28:46 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19PuPt-0003o1-00 for dhcwg@ietf.org; Tue, 10 Jun 2003 21:28:45 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5B1UILV008212 for ; Tue, 10 Jun 2003 21:30:18 -0400 (EDT) Date: Tue, 10 Jun 2003 21:30:18 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] WG last call on draft-ietf-dhc-server-mib-08 (2nd last call) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The last call on draft-ietf-dhc-server-mib-08 will end on Monday, July 7. -------------- - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 11 03:12:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27926; Wed, 11 Jun 2003 03:12:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7BKB13190; Wed, 11 Jun 2003 03:11:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B78EB13076 for ; Wed, 11 Jun 2003 03:08:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27833 for ; Wed, 11 Jun 2003 03:08:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PzgK-0005Tt-00 for dhcwg@ietf.org; Wed, 11 Jun 2003 03:06:04 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19PzgJ-0005Tq-00 for dhcwg@ietf.org; Wed, 11 Jun 2003 03:06:03 -0400 Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KWZ4OWLP4A9B618P@vaxh.its.monash.edu.au> for dhcwg@ietf.org; Wed, 11 Jun 2003 16:56:03 +1000 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 789842000A for ; Wed, 11 Jun 2003 16:56:02 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id C220320015 for ; Wed, 11 Jun 2003 16:55:56 +1000 (EST) Date: Wed, 11 Jun 2003 16:55:56 +1000 From: Greg Daley To: dhcwg@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EE6D27C.8010308@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT Subject: [dhcwg] Announce: BoF Proposal: Detecting Network Attachment Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, There has been some interest in various IETF WGs regarding what to do when attaching to a network, and how to distinguish if a host has attached to a currently configured network or a new one. I believe that in DHC, this is being pursued for the purpose of quickly detecting movement upon joining a link. There is currently a BoF proposed for IETF57 which aims to discuss issues uncovered in DHC, Mobile-IP and Zeroconf WGs. The hope is that getting together people from these (and other) groups who are interested in the problems may lead to a unified approach to these problems (or at least only one approach each for IPv4 and IPv6). Here is the proposed BoF's description: Detecting Network Attachment (DNA) Proposed BoF Description: Network Attachment occurs when a host arrives on a new IP subnet. When attaching to a network, a host either already has a valid configuration for this subnet or must configure addresses. A host determines whether it requires additional configuration by Detecting Network Attachment. When a host has existing upper layer protocols sessions, it is important to receive a timely indication that attachment has occurred. This may be the case if a host is connected intermittently, is moving or has urgent data to transmit upon attachment to a link. For these nodes, it is also important detect if an acquired link is new, or has already been visited. This information may be used to distinguish between events where configuration must be initiated, or a host already has valid configuration. This meeting hopes to providing a forum for those interested in developing generic attachment detection technologies for IPv4 and IPv6. The BOF aims to: * Describe existing issues encountered in DHC, ZEROCONF and Mobileip WGs, which could benefit from work on detecting network attachment. * Define the problem scope, and environments where network attachment detection is desirable. * Determine if sufficient interest exists to form a Working Group on this topic. * Reach consensus on the area of work for a potential WG, including which problems are outside scope. --- If you are interested in this topic, and contributing to an agenda for the proposed BoF, please subscribe to the mailing list: dna@eng.monash.edu.au You may subscribe by sending an email to: majordomo@ecselists.eng.monash.edu.au with the words: subscribe dna in the body of the email. More information is available at the website: http://www.ctie.monash.edu.au/dna/ Greg Daley _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 11 16:33:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26796; Wed, 11 Jun 2003 16:33:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKX4m00683; Wed, 11 Jun 2003 16:33:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKShm00395 for ; Wed, 11 Jun 2003 16:28:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19857 for ; Wed, 11 Jun 2003 16:28:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QCB2-0003Rz-00 for dhcwg@ietf.org; Wed, 11 Jun 2003 16:26:36 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19QCB1-0003RU-00 for dhcwg@ietf.org; Wed, 11 Jun 2003 16:26:35 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BKS8LU016248 for ; Wed, 11 Jun 2003 16:28:08 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-128-107-131-76.cisco.com [128.107.131.76]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id QAA16206 for ; Wed, 11 Jun 2003 16:28:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20030611162755.02155df8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jun 2003 16:28:02 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Fwd: Announce: BoF Proposal: Detecting Network Attachment Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , A BOF that may be of interest to members of the dhc WG: >Date: Wed, 11 Jun 2003 17:00:51 +1000 >From: Greg Daley >Subject: Announce: BoF Proposal: Detecting Network Attachment >To: zeroconf@trapdoor.merit.edu > >Hi, > >There has been some interest in various IETF WGs >regarding what to do when attaching to a network, >and how to distinguish if a host has attached to >a currently configured network or a new one. > >I believe that in zeroconf, this may be of use in >detecting network resource conflicts upon joining >a link. > >There is currently a BoF proposed for IETF57 which >aims to discuss issues uncovered in DHC, Mobile-IP >and Zeroconf WGs. The hope is that getting together >people from these (and other) groups who are interested >in the problems may lead to a unified approach >to these problems (or at least only one approach each >for IPv4 and IPv6). > >Here is the proposed BoF's description: > > >Detecting Network Attachment (DNA) Proposed BoF Description: > >Network Attachment occurs when a host arrives on a new >IP subnet. When attaching to a network, a host either >already has a valid configuration for this subnet or >must configure addresses. A host determines whether >it requires additional configuration by Detecting Network >Attachment. > >When a host has existing upper layer protocols sessions, >it is important to receive a timely indication that >attachment has occurred. This may be the case if a host >is connected intermittently, is moving or has urgent data >to transmit upon attachment to a link. > >For these nodes, it is also important detect if an acquired >link is new, or has already been visited. This information >may be used to distinguish between events where >configuration must be initiated, or a host already has >valid configuration. > >This meeting hopes to providing a forum for those >interested in developing generic attachment detection >technologies for IPv4 and IPv6. > >The BOF aims to: > >* Describe existing issues encountered in DHC, ZEROCONF > and Mobileip WGs, which could benefit from work on > detecting network attachment. > >* Define the problem scope, and environments where network > attachment detection is desirable. > >* Determine if sufficient interest exists to form a > Working Group on this topic. > >* Reach consensus on the area of work for a potential WG, > including which problems are outside scope. >--- > > >If you are interested in this topic, and contributing to >an agenda for the proposed BoF, please subscribe to >the mailing list: dna@eng.monash.edu.au > >You may subscribe by sending an email to: > >majordomo@ecselists.eng.monash.edu.au > >with the words: > >subscribe dna > >in the body of the email. > >More information is available at the website: > >http://www.ctie.monash.edu.au/dna/ > > >Greg Daley > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 12 09:52:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10301; Thu, 12 Jun 2003 09:52:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDqHm22826; Thu, 12 Jun 2003 09:52:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDikm22379 for ; Thu, 12 Jun 2003 09:44:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10045 for ; Thu, 12 Jun 2003 09:44:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QSLd-0002QQ-00 for dhcwg@ietf.org; Thu, 12 Jun 2003 09:42:37 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QSLc-0002QN-00 for dhcwg@ietf.org; Thu, 12 Jun 2003 09:42:36 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5CDiCVI091051 for ; Thu, 12 Jun 2003 15:44:12 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 97830A93B9 for ; Thu, 12 Jun 2003 15:30:52 +0200 (CEST) Message-ID: <3EE8830F.8070401@ccrle.nec.de> Date: Thu, 12 Jun 2003 15:41:35 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Interop: Draft Test Description Available Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, please find a draft test description for the vienna interop on: http://www.dhcpv6.org/docs/vienna_interop_tests.pdf Cheers Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 13 10:02:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05440; Fri, 13 Jun 2003 10:02:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHmCa11566; Thu, 12 Jun 2003 13:48:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHjOm11262 for ; Thu, 12 Jun 2003 13:45:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20627 for ; Thu, 12 Jun 2003 13:45:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QW6V-0004hg-00 for dhcwg@ietf.org; Thu, 12 Jun 2003 13:43:15 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 19QW6U-0004hK-00 for dhcwg@ietf.org; Thu, 12 Jun 2003 13:43:14 -0400 Received: from [207.102.214.106] (helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 19QW83-00085C-00 for ; Thu, 12 Jun 2003 10:44:51 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 10:45:29 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D19801766983@homer.incognito.com.> From: "Cosmo, Patrick" To: dhcwg@ietf.org Date: Thu, 12 Jun 2003 10:45:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3310A.69733DE0" Subject: [dhcwg] RE: draft-ietf-dhc-server-override-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3310A.69733DE0 Content-Type: text/plain; charset="iso-8859-1" 1. This draft seems to change RFC 2131 in a (minor?) way: RFC 2131 states: "A DHCP server always returns its own address in the 'server identifier' option". This draft is intended to force the DHCP server to return some other address in the 'server identifier' option. Is it OK to have 2 RFCs conflict in this way? 2. If the relay agent forwards DHCP packets to multiple DHCP servers, inserting the same server identifier override sub-option at all times, a DHCP service can no longer (reliably) determine if the client is accepting an offer that it has made, or an offer made by some other DHCP service. Does this issue need to be addressed in this draft? 3. typo in section 5.0: "If a rouge DHCP relay " should read "If a rogue DHCP relay" ("rouge" vs. "rogue"). Patrick Cosmo Senior Product Engineer Incognito Software Inc Vancouver: (604) 688-4332 ext: 254 Toll-Free: 1-800-877-1856 http://www.incognito.com -----Original Message----- From: Mark Stapp [mailto:mjs@cisco.com] Sent: Friday, June 06, 2003 3:49 PM To: Ralph Droms Cc: namedroppers@ops.ietf.org; dhcwg@ietf.org; olaf@ripe.net; Bernard Aboba; Rob Austein; Thomas Narten; Erik.Nordmark@eng.sun.com Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length I've replied to Patrick; I'm not quite sure what more to do with issue [6]. The draft recommends using a ttl that's a fraction of the lease time, and recommends removing rrs promptly when the lease expires. There have been at least a couple of exchanges about this over the years, and the conclusion has always been that it's not possible to come up with a single set of values that are appropriate in every situation. Also, it's not possible to compel updaters to perform additional updates to 'back down' rrs' ttls as a lease approaches its expiration - that'll kill the dns server. As I noted in the other email I sent, the recommendations that are in the draft are the most up-to-date ones that I've been offered. We do have quite a bit of deployment experience with dhcp updates to dns, and this has not been an issue, as far as I can recall. I also don't recall any email to the wg indicating that this has been an issue in anyone else's experience. If someone has followed these recommendations and has found problems with them, then by all means let's come up with better recommendations. -- Mark At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The RR TTLs need careful attention so that it never exceeds the > expiration time of the lease on the associated address. > >This issue was anticipated by Patrick Cosmo: > >On Fri, 6 Jun 2003, Cosmo, Patrick wrote: > > > I have found some minor issues with the > > , I apologize if they have already > > been brought up. > > > > In particular, this statement in section 5. (DNS RR TTLs) on page 5: > > > > "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed > > 1/3 of the lease time, and SHOULD be at least 10 minutes." > > > > 1. This sentence has some bad grammar ("for with" : ... record added for > > with a DHCP lease ...). > > > > 2. The statement is contradictory if the lease time is less than 30 > minutes. > > When the lease time is less than 30 minutes, which suggestion takes > > precendence? : min. 10 minutes, or max or 1/3 lease time? > > > > 3. The section seems intended to suggest a reasonable TTL for these > records, > > but doesn't seem to pull through or suggest much of anything (IMHO) other > > than "it should be a function of lease time, and it should be > configurable". > > > > > > Patrick Cosmo > > > > Senior Product Engineer > > Incognito Software Inc > > Vancouver: (604) 688-4332 ext: 254 > > Toll-Free: 1-800-877-1856 > > http://www.incognito.com > > > > > > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Thursday, June 05, 2003 7:36 PM > > To: dhcwg@ietf.org; namedroppers@ops.ietf.org > > Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > > > > > > The following drafts have passed WG last call: > > > > [1] A DNS RR for Encoding DHCP Information (DHCID RR) > > > > > > [2] The DHCP Client FQDN Option > > > > > > [3] Resolution of DNS Name Conflicts Among DHCP Clients > > > > > > Several issues regarding these drafts have been identified > > during the AD review prior to IESG review for Proposed > > Standard status. I will initiate discussion threads on > > each of these issues later today with e-mail to both > > the dhcwg and namedroppers mailing lists. Please respond > > just to the dhcwg mailing list to avoid duplicate postings... > > > > - Ralph > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C3310A.69733DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-dhc-server-override-00.txt

1. This draft seems to change RFC 2131 in a (minor?) = way: RFC 2131 states: "A DHCP server always returns its own = address in the 'server identifier' option". This draft is intended = to force the DHCP server to return some other address in the 'server = identifier' option. Is it OK to have 2 RFCs conflict in this = way?

2. If the relay agent forwards DHCP packets to = multiple DHCP servers, inserting the same server identifier override = sub-option at all times, a DHCP service can no longer (reliably) = determine if the client is accepting an offer that it has made, or an = offer made by some other DHCP service. Does this issue need to be = addressed in this draft?

3. typo in section 5.0: "If a rouge DHCP relay = " should read "If a rogue DHCP relay" ("rouge" = vs. "rogue").

Patrick Cosmo
 
Senior Product Engineer
Incognito Software Inc
Vancouver: (604) 688-4332 ext: 254
Toll-Free: 1-800-877-1856
http://www.incognito.com
 




-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Friday, June 06, 2003 3:49 PM
To: Ralph Droms
Cc: namedroppers@ops.ietf.org; dhcwg@ietf.org; = olaf@ripe.net; Bernard
Aboba; Rob Austein; Thomas Narten; = Erik.Nordmark@eng.sun.com
Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship = between DNS TTL and
DHCP lease length


I've replied to Patrick; I'm not quite sure what more = to do with issue [6].

The draft recommends using a ttl that's a fraction of = the lease time, and
recommends removing rrs promptly when the lease = expires. There have been at
least a couple of exchanges about this over the = years, and the conclusion
has always been that it's not possible to come up = with a single set of
values that are appropriate in every situation. = Also, it's not possible to
compel updaters to perform additional updates to = 'back down' rrs' ttls as a
lease approaches its expiration - that'll kill the = dns server. As I noted
in the other email I sent, the recommendations that = are in the draft are
the most up-to-date ones that I've been = offered.

We do have quite a bit of deployment experience with = dhcp updates to dns,
and this has not been an issue, as far as I can = recall. I also don't recall
any email to the wg indicating that this has been an = issue in anyone else's
experience. If someone has followed these = recommendations and has found
problems with them, then by all means let's come up = with better
recommendations.

-- Mark

At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote:
>DDNS-DHCP issue:
>
>    The RR TTLs need careful = attention so that it never exceeds the
>    expiration time of the lease = on the associated address.
>
>This issue was anticipated by Patrick = Cosmo:
>
>On Fri, 6 Jun 2003, Cosmo, Patrick wrote:
>
> > I have found some minor issues with = the
> > = <draft-ietf-dhc-ddns-resolution-05.txt>, I apologize if they have = already
> > been brought up.
> >
> > In particular, this statement in section = 5. (DNS RR TTLs) on page 5:
> >
> > "The RR TTL on a DNS record added for = with a DHCP lease SHOULD NOT exceed
> > 1/3 of the lease time, and SHOULD be at = least 10 minutes."
> >
> > 1. This sentence has some bad grammar = ("for with" : ... record added for
> > with a DHCP lease ...).
> >
> > 2. The statement is contradictory if the = lease time is less than 30
> minutes.
> > When the lease time is less than 30 = minutes, which suggestion takes
> > precendence? : min. 10 minutes, or max or = 1/3 lease time?
> >
> > 3. The section seems intended to suggest a = reasonable TTL for these
> records,
> > but doesn't seem to pull through or = suggest much of anything (IMHO) other
> > than "it should be a function of = lease time, and it should be
> configurable".
> >
> >
> > Patrick Cosmo
> >
> > Senior Product Engineer
> > Incognito Software Inc
> > Vancouver: (604) 688-4332 ext: 254
> > Toll-Free: 1-800-877-1856
> > http://www.incognito.com
> >
> >
> >
> > -----Original Message-----
> > From: Ralph Droms [mailto:rdroms@cisco.com]
> > Sent: Thursday, June 05, 2003 7:36 = PM
> > To: dhcwg@ietf.org; = namedroppers@ops.ietf.org
> > Subject: [dhcwg] Issues in DDNS-DHCP = interaction drafts
> >
> >
> > The following drafts have passed WG last = call:
> >
> > [1] A DNS RR for Encoding DHCP Information = (DHCID RR)
> >     = <draft-ietf-dnsext-dhcid-rr-06.txt>
> >
> > [2] The DHCP Client FQDN Option
> >     = <draft-ietf-dhc-fqdn-option-05.txt>
> >
> > [3] Resolution of DNS Name Conflicts Among = DHCP Clients
> >     = <draft-ietf-dhc-ddns-resolution-05.txt>
> >
> > Several issues regarding these drafts have = been identified
> > during the AD review prior to IESG review = for Proposed
> > Standard status.  I will initiate = discussion threads on
> > each of these issues later today with = e-mail to both
> > the dhcwg and namedroppers mailing = lists.  Please respond
> > just to the dhcwg mailing list to avoid = duplicate postings...
> >
> > - Ralph
> >
> > = _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

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

------_=_NextPart_001_01C3310A.69733DE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 18 07:37:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27470; Wed, 18 Jun 2003 07:37:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbFN-0003wc-6N; Wed, 18 Jun 2003 07:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbF0-0003vq-Gj for dhcwg@optimus.ietf.org; Wed, 18 Jun 2003 07:36:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27451 for ; Wed, 18 Jun 2003 07:36:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SbCk-0002Fh-00 for dhcwg@ietf.org; Wed, 18 Jun 2003 07:34:18 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19SbCk-0002Fa-00 for dhcwg@ietf.org; Wed, 18 Jun 2003 07:34:18 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5IBa5wH026158 for ; Wed, 18 Jun 2003 07:36:05 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-244.cisco.com [10.82.240.244]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id HAA28533 for ; Wed, 18 Jun 2003 07:36:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20030616101233.046bbef0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jun 2003 07:34:23 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] dhc WG meeting in Vienna Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The current agend for the IETF meeting in Vienna shows the dhc WG scheduled for Tue AM: TUESDAY, July 15, 2003 0900-1130 Morning Sessions APP geopriv Geographic Location/Privacy WG GEN problem Problem Statement WG INT dhc Dynamic Host Configuration WG OPS mboned MBONE Deployment WG SEC enroll Credential and Provisioning BOF SUB mpls Multiprotocol Label Switching WG TSV ippm IP Performance Metrics WG TSV rohc Robust Header Compression WG The conflict with the problem WG is unfortunate; I had hoped to attend the problem WG meeting. If others think that conflict (or another) is important, I'll see if we can reschedule something to avoid the conflict. If you have any agenda topics for the dhc WG meeting in Vienna, please contact me AS SOON AS POSSIBLE so I can submit a draft agenda. Our agenda will be a little different in Vienna. In an effort to move as much of our business to the WG mailing list as possible, I will draft and publish a status report to the mailing list prior to the Vienna meeting, rather than reviewing the status report at the meeting itself. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 18 09:37:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06356; Wed, 18 Jun 2003 09:37:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SckH-000080-Rz; Wed, 18 Jun 2003 09:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ScgV-0008PA-BE for dhcwg@optimus.ietf.org; Wed, 18 Jun 2003 09:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04358 for ; Wed, 18 Jun 2003 09:09:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SceE-00041M-00 for dhcwg@ietf.org; Wed, 18 Jun 2003 09:06:46 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19Sce9-0003zr-00 for dhcwg@ietf.org; Wed, 18 Jun 2003 09:06:46 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5ID8MX24175 for ; Wed, 18 Jun 2003 09:08:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 09:08:22 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E606C67C1F@zcard0ke.ca.nortel.com> From: "Glenn Waters" To: dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-server-mib-08 (2nd las t call) Date: Wed, 18 Jun 2003 09:08:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3359A.B1D3CF70" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3359A.B1D3CF70 Content-Type: text/plain I approve of moving this document forward. /gww > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, June 10, 2003 21:30 > To: dhcwg@ietf.org > Subject: [dhcwg] WG last call on draft-ietf-dhc-server-mib-08 (2nd last > call) > > > The last call on draft-ietf-dhc-server-mib-08 will > end on Monday, July 7. > -------------- > > > - Ralph > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C3359A.B1D3CF70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on draft-ietf-dhc-server-mib-08 (2nd = last call)

I approve of moving this document forward.

/gww

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Tuesday, June 10, 2003 21:30
> To: dhcwg@ietf.org
> Subject: [dhcwg] WG last call on = draft-ietf-dhc-server-mib-08 (2nd last
> call)
>
>
> The last call on draft-ietf-dhc-server-mib-08 = will
> end on Monday, July 7.
>        = --------------
>
>
> - Ralph
>
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C3359A.B1D3CF70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 18 09:50:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06937; Wed, 18 Jun 2003 09:50:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd9R-0001Fp-AB; Wed, 18 Jun 2003 09:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SclY-00008R-5p for dhcwg@optimus.ietf.org; Wed, 18 Jun 2003 09:14:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04859 for ; Wed, 18 Jun 2003 09:14:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ScjH-0004BX-00 for dhcwg@ietf.org; Wed, 18 Jun 2003 09:11:59 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19ScjG-0004AY-00 for dhcwg@ietf.org; Wed, 18 Jun 2003 09:11:58 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5IDDjwH016289; Wed, 18 Jun 2003 09:13:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-244.cisco.com [10.82.240.244]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA03051; Wed, 18 Jun 2003 09:13:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jun 2003 09:12:03 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I originally posed the issue: The RR TTLs need careful attention so that it never exceeds the expiration time of the lease on the associated address. Ed Lewis has suggested an alternative wording (based on his e-mail, included below): The RR TTLs need careful attention so that cached DNS information is never in conflict with the current assignment of an IP address to a host. That is, the important problem to avoid is cached DNS information about an address that has been assigned to a different host. Based on Ed's take on the problem, an alternative solution to the TTL problem is to: * the DHCP server adds an RR for host H with TTL set to some fixed value t * the DHCP server removes the RR when the lease on the address assigned to H expires at time T * the DHCP server does not make the address previously assigned to H available for reassignment until T+t Another observation - is it possible that the issue of stale cached DNS information has never been an issue in practice because DNS information installed by a DHCP server is rarely used, so that stale DNS information is insignificant? Put another way, do we have any experience with DDNS updates for a host that has obtained its IP address through DHCP and that is the target of frequent DNS queries; for example, a host running a web server whose address is found through a DNS query? If the RRs installed by the DHCP server are rarely queried, another alternative would be to simply set the TTL to 0, or to set the TTL initially to t, and then t seconds before the expiration of the lease on the address, set the TTL to 0. It seems that the guidance currently given in draft-ietf-dhc-ddns-resolution-05 will lead to a period of time equal to 1/3 the original lease time during which cached DNS data may associate a DNS name with an IP address that has been reassigned to a different host. This potential problem may not have been realized in practice because the DNS information about a host updated by a DHCP server is rarely queried. - Ralph At 08:19 PM 6/11/2003 -0400, Edward Lewis wrote: >Let's face it, DNS doesn't handle change well. And, worse yet, neither does security. That and DHCP , the reason we are here, loves change. > >One problem is that we are once again (to DNS'ers) mixing relative time (TTLs) and absolute time (a lease is from fixed time A to fixed time B). (I realize a lease can be extended, renewed, etc., but at any moment, it's a fixed span.) The same problem exists in DNSSEC's signature records and their validity spans. The concrete dilemma is - if I set the TTL to be (B-A)/3, as suggested, then the PTR/A[AAA] record will have the same value whether t=A or t=B. > >The best thing would be for a merge of the DNS server and DHCP server so that the TTL is always set to (B-NOW)-fudge, which is what we really want. 'Course, if we also wanted DNSSEC, we'd have to sign on the fly (which is why I mentioned security above). > >I'd suggest that if the DHCP server has a period of time in which it will not reassign/reallocate an address after a lease has been allowed to elapse, that this is the period to use for the TTL. It represents the amount of time that erroneous information in a DNS cache can exist and not be of harm to an active node. > >The DNS data is just as "dirty" but if the DHCP hasn't given the address to another node, there's a win in there somewhere. > >At 15:48 -0400 6/6/03, Mark Stapp wrote: >>I've replied to Patrick; I'm not quite sure what more to do with issue [6]. >> >>The draft recommends using a ttl that's a fraction of the lease time, and recommends removing rrs promptly when the lease expires. There have been at least a couple of exchanges about this over the years, and the conclusion has always been that it's not possible to come up with a single set of values that are appropriate in every situation. Also, it's not possible to compel updaters to perform additional updates to 'back down' rrs' ttls as a lease approaches its expiration - that'll kill the dns server. As I noted in the other email I sent, the recommendations that are in the draft are the most up-to-date ones that I've been offered. >> >>We do have quite a bit of deployment experience with dhcp updates to dns, and this has not been an issue, as far as I can recall. I also don't recall any email to the wg indicating that this has been an issue in anyone else's experience. If someone has followed these recommendations and has found problems with them, then by all means let's come up with better recommendations. >> >>-- Mark >> >>At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote: >>>DDNS-DHCP issue: >>> >>> The RR TTLs need careful attention so that it never exceeds the >>> expiration time of the lease on the associated address. >>> >>>This issue was anticipated by Patrick Cosmo: >>> >>>On Fri, 6 Jun 2003, Cosmo, Patrick wrote: >>> >>> > I have found some minor issues with the >>> > , I apologize if they have already >>> > been brought up. >>> > >>> > In particular, this statement in section 5. (DNS RR TTLs) on page 5: >>> > >>> > "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed >>> > 1/3 of the lease time, and SHOULD be at least 10 minutes." >>> > >>> > 1. This sentence has some bad grammar ("for with" : ... record added for >>> > with a DHCP lease ...). >>> > >>> > 2. The statement is contradictory if the lease time is less than 30 minutes. >>> > When the lease time is less than 30 minutes, which suggestion takes >>> > precendence? : min. 10 minutes, or max or 1/3 lease time? >>> > >>> > 3. The section seems intended to suggest a reasonable TTL for these records, >>> > but doesn't seem to pull through or suggest much of anything (IMHO) other >>> > than "it should be a function of lease time, and it should be configurable". >>> > >>> > >>> > Patrick Cosmo >>> > >>> > Senior Product Engineer >>> > Incognito Software Inc >>> > Vancouver: (604) 688-4332 ext: 254 >>> > Toll-Free: 1-800-877-1856 >>> > http://www.incognito.com >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: Ralph Droms [mailto:rdroms@cisco.com] >>> > Sent: Thursday, June 05, 2003 7:36 PM >>> > To: dhcwg@ietf.org; namedroppers@ops.ietf.org >>> > Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts >>> > >>> > >>> > The following drafts have passed WG last call: >>> > >>> > [1] A DNS RR for Encoding DHCP Information (DHCID RR) >>> > >>> > >>> > [2] The DHCP Client FQDN Option >>> > >>> > >>> > [3] Resolution of DNS Name Conflicts Among DHCP Clients >>> > >>> > >>> > Several issues regarding these drafts have been identified >>> > during the AD review prior to IESG review for Proposed >>> > Standard status. I will initiate discussion threads on >>> > each of these issues later today with e-mail to both >>> > the dhcwg and namedroppers mailing lists. Please respond >>> > just to the dhcwg mailing list to avoid duplicate postings... >>> > >>> > - Ralph >>> > >>> > _______________________________________________ >>> > dhcwg mailing list >>> > dhcwg@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/dhcwg >>> > >>>_______________________________________________ >>>dhcwg mailing list >>>dhcwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dhcwg >> >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-703-227-9854 >ARIN Research Engineer > >Okay, okay, the previous sig wasn't all that good... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 18 10:35:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10004; Wed, 18 Jun 2003 10:35:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SddR-0002z7-1f; Wed, 18 Jun 2003 10:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdBi-0001KK-MO for dhcwg@optimus.ietf.org; Wed, 18 Jun 2003 09:41:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06544 for ; Wed, 18 Jun 2003 09:41:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sd9R-0004jv-00 for dhcwg@ietf.org; Wed, 18 Jun 2003 09:39:01 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 19Sd9R-0004iV-00 for dhcwg@ietf.org; Wed, 18 Jun 2003 09:39:01 -0400 Received: from [207.102.214.106] (helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 19SdBB-0005Qn-00 for ; Wed, 18 Jun 2003 06:40:49 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 06:41:41 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198017669DE@homer.incognito.com.> From: "Cosmo, Patrick" To: dhcwg@ietf.org Date: Wed, 18 Jun 2003 06:41:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3359F.590926B0" Subject: [dhcwg] FW: Last Call Extended for DHCP Server MIB Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3359F.590926B0 Content-Type: text/plain; charset="iso-8859-1" >I'm calling on each of you to take a last, quick look at >draft-ietf-dhcp-server-mib-08.txt and respond to the >DHC mailing list with "Yes," "No," or offering comments >and suggestions. Yes. -----Original Message----- From: Barr Hibbs [mailto:rbhibbs@pacbell.net] Sent: Tuesday, June 17, 2003 5:53 PM To: Multiple Recipients Subject: Last Call Extended for DHCP Server MIB I'm calling on each of you to take a last, quick look at draft-ietf-dhcp-server-mib-08.txt and respond to the DHC mailing list with "Yes," "No," or offering comments and suggestions. Because of the limited response to the first and second WG last calls on "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB" I am soliciting any and all comments regarding this work prior to the Vienna meeting of the DHC Working Group. Please respond to the DHC working group mailing list. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of response to the WG last call will be interpreted as an indication that the document should not be submitted to the IESG for review. draft-ietf-dhc-server-mib-08.txt defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol for IPv4 (DHCPv4) and Bootstrap Protocol (BOOTP) servers. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-08.txt Thank you for your interest and aid in the development of this MIB. --Barr ------_=_NextPart_001_01C3359F.590926B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Last Call Extended for DHCP Server MIB

>I'm calling on each of you to take a last, quick = look at
>draft-ietf-dhcp-server-mib-08.txt and respond to = the
>DHC mailing list with "Yes," = "No," or offering comments
>and suggestions.

Yes.

-----Original Message-----
From: Barr Hibbs [mailto:rbhibbs@pacbell.net]
Sent: Tuesday, June 17, 2003 5:53 PM
To: Multiple Recipients
Subject: Last Call Extended for DHCP Server = MIB



I'm calling on each of you to take a last, quick look = at
draft-ietf-dhcp-server-mib-08.txt and respond to the = DHC mailing list with
"Yes," "No," or offering = comments and suggestions.

Because of the limited response to the first and = second WG last calls on
"Dynamic Host Configuration Protocol for IPv4 = (DHCPv4) Server MIB" I am
soliciting any and all comments regarding this work = prior to the Vienna
meeting of the DHC Working Group.

Please respond to the DHC working group mailing = list.  If you support
acceptance of the document without change, respond = with a simple
acknowledgment, so that support for the document can = be assessed.  Lack of
response to the WG last call will be interpreted as = an indication that the
document should not be submitted to the IESG for = review.

draft-ietf-dhc-server-mib-08.txt defines an = experimental portion of
the Management Information Base (MIB) for use with = network management
protocols in the Internet Community.  In = particular, it defines
objects used for the management of Dynamic Host = Configuration Protocol
for IPv4 (DHCPv4) and Bootstrap Protocol (BOOTP) = servers. This
document is being considered for Proposed Standard, = and is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-ser= ver-mib-08.txt

Thank you for your interest and aid in the = development of this MIB.

--Barr

------_=_NextPart_001_01C3359F.590926B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 19 07:56:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10715; Thu, 19 Jun 2003 07:56:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sxg1-0001ps-MN; Thu, 19 Jun 2003 07:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxVl-0001Us-NJ for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 07:23:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08879 for ; Thu, 19 Jun 2003 07:23:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SxTU-0001nD-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 07:21:04 -0400 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 19SxTC-0001n0-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 07:21:02 -0400 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5JBMEr07640; Thu, 19 Jun 2003 18:22:15 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5JBJGY01881; Thu, 19 Jun 2003 18:19:16 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> References: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Jun 2003 18:19:16 +0700 Message-ID: <14436.1056021556@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Wed, 18 Jun 2003 09:12:03 -0400 From: Ralph Droms Message-ID: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> | That is, the important problem to avoid is cached DNS | information about an address that has been assigned | to a different host. Maybe there's something missing here, but I don't understand why this is supposed to be an important problem. That is, reworded, to make sure my understanding is correct, the problem to be avoided is having a name referring to an address that is now to be assigned to a different name ? Who cares? I mean, it is nice to have everything cleaned up, but there's nothing that can be done that can possibly guarantee that there isn't another name around referring to a particular address (there's no practical way to locate one - that would require IQUERY which we don't have...) The problem that you want to avoid, is having an old address still associated with the name to which a new address is being assigned. That's because it starts to be a gamble which address you will get when the name is looked up (depending upon which server happens to respond, and which cache contains what information). | Based on Ed's take on the problem, an alternative solution | to the TTL problem is to: | | * the DHCP server adds an RR for host H with TTL set | to some fixed value t | * the DHCP server removes the RR when the lease on the | address assigned to H expires at time T At this point, the old address for H is still potentially floating around the DNS until T+R+r*n+t (worst case, T+E+t) - where R is the "refresh" timer in the SOA, 'r' is the retry timer, n is the number of refresh retries it takes (n >= 0), and 'E' is the zone expire timer). | * the DHCP server does not make the address previously | assigned to H available for reassignment until T+t That achieves nothing useful in any practical sense. What is needed would be to not assign H a new (different) address until after (at least T+t) (but to be ultra safe, T+E+t). Of course, doing that means causing H to be without an address for something (which in some zones) may be as long as a month. Hardly practical. | Another observation - is it possible that the issue of | stale cached DNS information has never been an issue | in practice because DNS information installed by a DHCP | server is rarely used, so that stale DNS information | is insignificant? Most likely, yes. If 't' isn't set very large (which for dynamically assigned addresses it should not be) and the DNS servers communicate with each other properly, the only effect is that someone attempting to contact the host with the dnuamic address, by name, might fail for a while after a new assignment has been made. Most hosts with dynamic addresses aren't contacted by name anyway. | If the RRs installed by the DHCP server are rarely queried, | another alternative would be to simply set the TTL to 0, | or to set the TTL initially to t, and then t seconds | before the expiration of the lease on the address, set | the TTL to 0. Those can help, but the 't' interval isn't really the one to worry about, the hard case is where a secondary server has the old information and then loses contact with the primary server - and you have to wait for its copy of the zone to expire before it stops handing out the bad address. | It seems that the guidance currently given in | draft-ietf-dhc-ddns-resolution-05 will lead to a period | of time equal to 1/3 the original lease time during | which cached DNS data may associate a DNS name with | an IP address that has been reassigned to a different | host. This potential problem may not have been realized | in practice because the DNS information about a host | updated by a DHCP server is rarely queried. That potential problem hasn't been realised because no-one would care in the slightest if it happened. This is simply irrelevant. I'm sure the problem of attempting to contact a host, and being told to try its previous address, has been seen, but rarely. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 19 08:04:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11152; Thu, 19 Jun 2003 08:04:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sxkr-0002Gc-99; Thu, 19 Jun 2003 07:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sxc0-0001fj-B5 for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 07:29:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09006; Thu, 19 Jun 2003 07:29:50 -0400 (EDT) Message-Id: <200306191129.HAA09006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 19 Jun 2003 07:29:50 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-v4-threat-analysis-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis Author(s) : R. Hibbs et al. Filename : draft-ietf-dhc-v4-threat-analysis-00.txt Pages : 19 Date : 2003-6-18 DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration of host systems in a TCP/IPv4 network. It 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 for 2003 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-v4-threat-analysis-00.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-v4-threat-analysis-00.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: <2003-6-18121739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-v4-threat-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-v4-threat-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-18121739.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 19 11:06:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23843; Thu, 19 Jun 2003 11:06:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0zB-0006EF-Oa; Thu, 19 Jun 2003 11:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0yb-0006Ci-M5 for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 11:05:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23720 for ; Thu, 19 Jun 2003 11:05:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0wH-0005OX-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 11:03:01 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19T0wF-0005MT-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 11:03:00 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JF4mO1008468 for ; Thu, 19 Jun 2003 11:04:48 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-720.cisco.com [10.82.242.208]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA00330 for ; Thu, 19 Jun 2003 11:04:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20030619105950.04933940@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 11:02:51 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Fwd: WG last call: draft-ietf-zeroconf-ipv4-linklocal-08.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , FYI ... dhc WG members may want to review this draft, as there are aspects of it that affect the DHCP specification. - Ralph >Date: Tue, 10 Jun 2003 11:05:59 +0200 >From: Erik Guttman >To: zeroconf@merit.edu >Subject: WG last call: draft-ietf-zeroconf-ipv4-linklocal-08.txt > > >In the interest of expediency, I am starting a 2 week working group >last call on the link-local document. Please send comments to the >WG mailing list until June 24, 2003. > >The comments sent by Stuart on past issues in recent days should be >considered as part of the last call discussion. > >I believe the issues at hand are settled well enough, and well enough >understood, that we can reach a consensus on questions that emerge >*during the WG last call period.* That is, we are departing from the >'issue by issue' procedure we have followed since February to attempt >to wrap this document up. > >Please see: >http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-08.txt > >Thanks, > >Erik > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 19 17:26:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19364; Thu, 19 Jun 2003 17:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T6uv-0001Eg-MA; Thu, 19 Jun 2003 17:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T6jy-0000XL-4A for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 17:14:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18840 for ; Thu, 19 Jun 2003 17:14:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T6hf-0003Q9-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 17:12:19 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19T6he-0003Q6-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 17:12:18 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 1AA4E1B2003; Thu, 19 Jun 2003 16:13:08 -0500 (CDT) From: Ted Lemon To: Robert Elz Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Date: Thu, 19 Jun 2003 12:40:56 -0500 User-Agent: KMail/1.5 References: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> In-Reply-To: <14436.1056021556@munnari.OZ.AU> Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306191240.56057.mellon@fugue.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday 19 June 2003 06:19, Robert Elz wrote: > That is, reworded, to make sure my understanding is correct, the > problem to be avoided is having a name referring to an address that > is now to be assigned to a different name ? > > Who cares? Let's say machine X has an SMTP listener, and machine Y also has an SMTP listener. Machine X gets an IP address, Z, from the DHCP server. Then the owner of Machine X wanders away, leaving the lease active. The lease expires, and then machine Y gets the address. But there is still an A record for machine X pointing at IP address Z. So now, machine Q connects to Z because of that A record, and tries to drop mail for X on Y. Y will either bounce it immediately, or bounce it after it notices that the A record for X is pointing at it. So we'd really like it if the time that the A record goes away and the time that the lease goes away are fairly close together, so that the chances of this happening are slim. Of course, I would say that this is a broken configuration anyway - you really want to use protocols that verify who they're talking to if you have a mobile computer. But that's the basis for caring about this sort of thing, and while I don't think we can completely solve the problem, it's worth setting things up to minimize the damage that occurs in cases like this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 19 17:36:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19817; Thu, 19 Jun 2003 17:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T74b-0001ur-OB; Thu, 19 Jun 2003 17:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T741-0001u2-30 for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 17:35:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19774 for ; Thu, 19 Jun 2003 17:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T71h-0003eL-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 17:33:01 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19T71h-0003e6-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 17:33:01 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JLYmO1009111; Thu, 19 Jun 2003 17:34:49 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-720.cisco.com [10.82.242.208]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id RAA02180; Thu, 19 Jun 2003 17:34:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20030619173047.047deaf0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 17:33:07 -0400 To: Ted Lemon From: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: Robert Elz , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200306191240.56057.mellon@fugue.com> References: <14436.1056021556@munnari.OZ.AU> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I agree with Ted ... in fact, I had a conversation about exactly this problem earlier today. In theory, any application shouldn't depend on just DNS to identify and establish contact with the correct endpoint (server). In practice, we have many such applications deployed today, so we should be careful not to provide another path for breakage... - Ralph At 12:40 PM 6/19/2003 -0500, Ted Lemon wrote: >On Thursday 19 June 2003 06:19, Robert Elz wrote: > > That is, reworded, to make sure my understanding is correct, the > > problem to be avoided is having a name referring to an address that > > is now to be assigned to a different name ? > > > > Who cares? > >Let's say machine X has an SMTP listener, and machine Y also has an SMTP >listener. Machine X gets an IP address, Z, from the DHCP server. Then the >owner of Machine X wanders away, leaving the lease active. The lease >expires, and then machine Y gets the address. But there is still an A >record for machine X pointing at IP address Z. So now, machine Q connects >to Z because of that A record, and tries to drop mail for X on Y. Y will >either bounce it immediately, or bounce it after it notices that the A record >for X is pointing at it. So we'd really like it if the time that the A >record goes away and the time that the lease goes away are fairly close >together, so that the chances of this happening are slim. > >Of course, I would say that this is a broken configuration anyway - you >really >want to use protocols that verify who they're talking to if you have a mobile >computer. But that's the basis for caring about this sort of thing, and >while I don't think we can completely solve the problem, it's worth setting >things up to minimize the damage that occurs in cases like this. > > >_______________________________________________ >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-admin@ietf.org Thu Jun 19 17:46:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20587; Thu, 19 Jun 2003 17:46:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7EI-00039l-GO; Thu, 19 Jun 2003 17:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7Dy-00038o-Ec for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 17:45:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20514 for ; Thu, 19 Jun 2003 17:45:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T7Bf-0003pJ-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 17:43:19 -0400 Received: from ip25.coe.tnet.co.th ([203.146.155.25] helo=fuchsia.home) by ietf-mx with esmtp (Exim 4.12) id 19T7Bc-0003pF-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 17:43:17 -0400 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h5JLiqlw018239; Fri, 20 Jun 2003 04:44:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5JLcPF14809; Fri, 20 Jun 2003 04:38:27 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <200306191240.56057.mellon@fugue.com> References: <200306191240.56057.mellon@fugue.com> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jun 2003 04:38:25 +0700 Message-ID: <22680.1056058705@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Thu, 19 Jun 2003 12:40:56 -0500 From: Ted Lemon Message-ID: <200306191240.56057.mellon@fugue.com> | So now, machine Q connects to Z because of that A record, and tries | to drop mail for X on Y. Y will either bounce it immediately, | or bounce it after it notices that the A record for X is pointing at it. And if the A record had been deleted, the mail would just have bounced. That's a lot of diffrence... (yes, I know in the latter case there could be a lower priority MX, which would take the mail, but then it would ...) | So we'd really like it if the time that the A | record goes away and the time that the lease goes away are fairly close | together, so that the chances of this happening are slim. No problem with that, I agree that cleanup is a good idea, and getting rid of old stuff ought be done. I just don't see the particular problem as being anything so serious that it warrants particular attention. That is, the more serious problem is not being able to connect to a host that you should be able to connect to, because you were given an out of date address, than not being able to connect to a host that you cannot possibly connect to anyway, because its address is now in use by someone different. | Of course, I would say that this is a broken configuration anyway Agree, but broken or not, those are configurations that people use, so if it did cause serious problems, we'd need to worry about, and fix them. I just don't see the problems as so serious that anyone needs to devote much attention to them. Or, put it another way, anyone, anywhere, can stick any address in a A (or AAAA) record. That can easily cause some random other name to refer to a host which has its own name mapped to the same address. This is with or without DHCP being involved. You cannot possibly hope to make that name go away, or change its A record (you cannot even find it). I suspect though, that if the dhcp server, when updating the DNS, does the best job it can to make sure that old addresses aren't floating around for the name it is managing, that will (by some happy co-incidence) also cause the problem that was mentioned as being serious (which isn't) to get solved at the same time. That is, there are 2 names involved, each being managed by a separate instance of the state machine - rather than having one of those attempt to clean up the other one (by not allowing the address to be allocated for an extra delay period - which would be a nightmare in some address deprived environments) just allow each to clean up after itself. That way the old address for name X gets deleted, when the lease expires, or as close to that as practical, which also means that X no longer has the address that we want to now assign to Y, and we don't have to delay that assignment to make it happen. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 19 18:08:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22071; Thu, 19 Jun 2003 18:08:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7ZY-0004fd-Uv; Thu, 19 Jun 2003 18:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7Ye-0004Rq-Bk for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 18:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21913 for ; Thu, 19 Jun 2003 18:07:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T7WK-00045N-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 18:04:40 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19T7WJ-00044u-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 18:04:39 -0400 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JM6SO2017321; Thu, 19 Jun 2003 18:06:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20030619174731.01fe6eb8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 18:06:23 -0400 To: Ted Lemon From: Mark Stapp Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: Robert Elz , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200306191240.56057.mellon@fugue.com> References: <14436.1056021556@munnari.OZ.AU> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Would this be a reasonable summary of the discussion on this topic? 1. the looseness of the coupling among primary, secondary, and caching dns servers makes it unrealistic to guarantee that no query will see stale records. the deployment experience that we have does not indicate that this is a problem. 2. this section of the draft should make the issues about dns ttls and caching more explicit, so that it's clearer what the operational consequences of 'stale' records might be. I'll add text about the benefits to removing dhcp-added dns records when leases expire. 3. the simple ttl guidelines that are in the draft are present to give implementors (and administrators) some clue about reasonable ranges and defaults. the guidelines are meant to help folks avoid hare-brained configurations (what Robert calls "minimizing damage"); the guidelines aren't intended to provide a guarantee about how long it may be before changes to the dns become universally visible. 4. it's not worthwhile to impose new requirements on DHCP servers to put names or addresses in limbo in some way for some period of time after leases expire. -- Mark At 12:40 PM 6/19/2003 -0500, Ted Lemon wrote: >On Thursday 19 June 2003 06:19, Robert Elz wrote: > > That is, reworded, to make sure my understanding is correct, the > > problem to be avoided is having a name referring to an address that > > is now to be assigned to a different name ? > > > > Who cares? > >Let's say machine X has an SMTP listener, and machine Y also has an SMTP >listener. Machine X gets an IP address, Z, from the DHCP server. Then the >owner of Machine X wanders away, leaving the lease active. The lease >expires, and then machine Y gets the address. But there is still an A >record for machine X pointing at IP address Z. So now, machine Q connects >to Z because of that A record, and tries to drop mail for X on Y. Y will >either bounce it immediately, or bounce it after it notices that the A record >for X is pointing at it. So we'd really like it if the time that the A >record goes away and the time that the lease goes away are fairly close >together, so that the chances of this happening are slim. > >Of course, I would say that this is a broken configuration anyway - you >really >want to use protocols that verify who they're talking to if you have a mobile >computer. But that's the basis for caring about this sort of thing, and >while I don't think we can completely solve the problem, it's worth setting >things up to minimize the damage that occurs in cases like this. > > >_______________________________________________ >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-admin@ietf.org Thu Jun 19 18:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23739; Thu, 19 Jun 2003 18:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7wn-0006bP-Cg; Thu, 19 Jun 2003 18:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7wD-0006Pk-D1 for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 18:31:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23692 for ; Thu, 19 Jun 2003 18:31:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T7tt-0004K8-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 18:29:01 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19T7ts-0004K4-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 18:29:01 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 904941B2003; Thu, 19 Jun 2003 17:29:50 -0500 (CDT) From: Ted Lemon (by way of Ted Lemon ) Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Date: Thu, 19 Jun 2003 15:31:18 -0500 User-Agent: KMail/1.5 To: dhcwg@ietf.org, namedroppers@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306191531.18596.mellon@nominum.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday 19 June 2003 17:06, you wrote: > Would this be a reasonable summary of the discussion on this topic? > [...] Yes. I think this sums it up nicely. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 19 20:02:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26124; Thu, 19 Jun 2003 20:02:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9Lt-00041m-6j; Thu, 19 Jun 2003 20:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9Id-0003hJ-EY for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 19:58:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25941 for ; Thu, 19 Jun 2003 19:58:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T9GK-0004qc-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 19:56:16 -0400 Received: from smtp1.arin.net ([192.149.252.33]) by ietf-mx with esmtp (Exim 4.12) id 19T9GJ-0004qT-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 19:56:16 -0400 Received: by smtp1.arin.net (Postfix, from userid 5003) id 04BAF33F; Thu, 19 Jun 2003 19:58:06 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 8DD3732F; Thu, 19 Jun 2003 19:58:06 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 411438; Thu, 19 Jun 2003 19:54:43 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20030619174731.01fe6eb8@goblet.cisco.com> References: <14436.1056021556@munnari.OZ.AU> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> <4.3.2.7.2.20030619174731.01fe6eb8@goblet.cisco.com> Date: Thu, 19 Jun 2003 19:55:15 -0400 To: Mark Stapp From: Edward Lewis Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: Ted Lemon , Robert Elz , dhcwg@ietf.org, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 18:06 -0400 6/19/03, Mark Stapp wrote: >Would this be a reasonable summary of the discussion on this topic? > >1. the looseness of the coupling among primary, secondary, and caching dns >servers makes it unrealistic to guarantee that no query will see stale >records. the deployment experience that we have does not indicate that this >is a problem. That's certainly true. My suggestion neglected the fact that a slave server could be out of date with respect to a master. (It's a problem less and less though with NOTIFY, but it's a possibility still.) >2. this section of the draft should make the issues about dns ttls and caching >more explicit, so that it's clearer what the operational consequences of >'stale' records might be. I'll add text about the benefits to removing >dhcp-added dns records when leases expire. Yup. >3. the simple ttl guidelines that are in the draft are present to give >implementors (and administrators) some clue about reasonable ranges and >defaults. the guidelines are meant to help folks avoid hare-brained >configurations (what Robert calls "minimizing damage"); the guidelines aren't >intended to provide a guarantee about how long it may be before changes to >the dns become universally visible. Yup. >4. it's not worthwhile to impose new requirements on DHCP servers to put names >or addresses in limbo in some way for some period of time after leases expire. Perhaps, I suppose that it isn't DHCP's problem if the DNS has too much persistence...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 19 23:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02047; Thu, 19 Jun 2003 23:34:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TCf3-0008Qt-EE; Thu, 19 Jun 2003 23:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TAK2-00075r-Py for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 21:04:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27462 for ; Thu, 19 Jun 2003 21:04:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TAHj-0005BN-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 21:01:47 -0400 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by ietf-mx with esmtp (Exim 4.12) id 19TAHi-0005BK-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 21:01:46 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5K145q29771 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 19 Jun 2003 21:04:07 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5K15hr12678; Thu, 19 Jun 2003 21:05:43 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h5K13rWl030720; Thu, 19 Jun 2003 21:03:53 -0400 Message-Id: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-reply-to: Your message of "Fri, 20 Jun 2003 04:38:25 +0700." <22680.1056058705@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Jun 2003 21:03:52 -0400 From: Michael Richardson Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- I came to this thread late. I can understand why this topic came up in the context of DHCP, but it is really a dynamic update issue. I use nsupdate to update the location of my laptop. I do this from my dhcp-client, my ppp "ip-up", and from some manual scripts that I use when all of the above is not useful. (which is less often, fortunately) The reason that I say that dhcp is not involved is because it is my laptop (not the dhcp server) that has the relationship with my forward domain server. As such, what I really want is a dynamic update operation which actually says "install this record with TTL=XXX, deleting the record after YYY" (Clearly, XXX < YYY, and some may argue YYY:=XXX. I'm undecided) I have really no problem sending a new update every couple of minutes. In fact, I'd prefer to do this. That way, the record goes away sometime after I go away or I loose connectivity, which is a lot better than the next time I get online! (And there are lots of places where DNS is forced-proxy, and dyn-update does not work. I started a list earlier this month, even: http://www.sandelman.ca/mcr/hotels/ actually) In the reverse map space, and in the places where the dhcpd server does control the forward map, sure - TTL should be less than lease time, and the dhcpd server SHOULD remove the record when the lease is returned to the pool. A timed-dynamic update would be easier for that situation too, I think. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPvJddoqHRg3pndX9AQG6CAP+Pz9gE5VzA5zmVyRrp7Lam7nMb/9USI5L nkQUQe7vqrVbwk6Ss8AMFM5+ZLRTCZEJ/3KfBMZqcrhMdaTDhIaOM3LnsPXYhn7p 15QkliFrn5DMd4AZKfgOLxgUN+EKEq/PY3E8bR0a2eWyrJct5nuQbRyeu/9Of2DQ 7/Jeme7A2Cw= =5++K -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 05:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23210; Fri, 20 Jun 2003 05:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIU0-0007NT-Th; Fri, 20 Jun 2003 05:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TITi-0007Go-Ai for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 05:46:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23193 for ; Fri, 20 Jun 2003 05:46:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TIRL-000197-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 05:44:15 -0400 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 19TIRK-00018j-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 05:44:14 -0400 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5K9jCr11939; Fri, 20 Jun 2003 16:45:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5K9iFH25906; Fri, 20 Jun 2003 16:44:15 +0700 (ICT) From: Robert Elz To: Michael Richardson cc: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> References: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jun 2003 16:44:14 +0700 Message-ID: <15427.1056102254@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Thu, 19 Jun 2003 21:03:52 -0400 From: Michael Richardson Message-ID: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> First, Mark's summary looked fine to me. But ... | As such, what I really want is a dynamic update operation which actually | says "install this record with TTL=XXX, deleting the record after YYY" | (Clearly, XXX < YYY, and some may argue YYY:=XXX. I'm undecided) The XXX & YYY relationship isn't important here but XXX << YYY (in the mathematical << sense, not "shift left") if this were to have any hope of working. But yes, that's what almost everyone wanted when dynamic update was being defined - and a lot of effort was spend attempting to find something which would actually work like that. Unfortunately, nothing reliable could be found, so that is not what exists. You can try and dream up a protocol to allow this to work, but first please go and review all the archives from when dynamic update was being designed, and then again since then whenever anyone has suggested it since - it is not nearly as simple to make work properly as it seems it should be - and if it can't be guaranteed to work, then the host has to deal with it other ways anyway. | I have really no problem sending a new update every couple of minutes. | In fact, I'd prefer to do this. Unfortunately, by itself, that doesn't help - that was the original plan for this (you need to investigate the way the whole DNS works, including the primary/secondary relationship, and servers that crash at inconvenient times, to see the problems). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 06:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23899; Fri, 20 Jun 2003 06:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TJ5l-0000ts-3S; Fri, 20 Jun 2003 06:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TJ5X-0000th-VD for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 06:25:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23891 for ; Fri, 20 Jun 2003 06:25:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TJ3B-0001Hy-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 06:23:21 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19TJ3A-0001Hv-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 06:23:20 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5KAPDO1015188; Fri, 20 Jun 2003 06:25:13 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-347.cisco.com [10.82.225.91]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id GAA04241; Fri, 20 Jun 2003 06:25:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20030620061756.0468bf98@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jun 2003 06:23:31 -0400 To: dhcwg@ietf.org From: Ralph Droms Cc: mankin@psg.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , FYI ... announcing a WG last call on draft-ietf-geopriv-dhcp-lci-option-01.txt. Please review the draft and 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. - Ralph >To: geopriv@mail.apps.ietf.org >Subject: Working Group Last Call: Location Configuration Information for >GEOPRIV >Date: Wed, 18 Jun 2003 22:51:40 -0700 >From: Allison Mankin > >This begins WGLC for Location Configuration Information for GEOPRIV, >draft-ietf-geopriv-dhcp-lci-option-01.txt. The WGLC will take place >in both the GEOPRIV and DHC WGs, and in consequence, will be allowed >three weeks rather than two, concluding Jul 10. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 08:44:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04117; Fri, 20 Jun 2003 08:44:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLFJ-00022Z-EL; Fri, 20 Jun 2003 08:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLEv-00022M-23 for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 08:43:37 -0400 Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03989 for ; Fri, 20 Jun 2003 08:43:32 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5KCgKr22832; Fri, 20 Jun 2003 19:42:24 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5KCcdH29618; Fri, 20 Jun 2003 19:38:40 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, mankin@psg.com, geopriv@mail.apps.ietf.org Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV In-Reply-To: <4.3.2.7.2.20030620061756.0468bf98@funnel.cisco.com> References: <4.3.2.7.2.20030620061756.0468bf98@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jun 2003 19:38:39 +0700 Message-ID: <12617.1056112719@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The definitions of altitude in that draft need work. Metres (positive and negative) is simple enough, but relative to what? Unless I missed it, I could find no definition of what is 0. If the assumption is that it is to be "mean sea level" then which sea? If it is to be above (+ or - below) ground level, which ground level within the designated area given by the latitude and longitude (sloping ground). When measured in floors, the "0" means ground level is fine, but how are floors counted? Is there some standard, or does anyone count them however they like. Can one assume that if some device is at altitude (as a floor) N, then something at N+2 will be two floors up? If N==12? How do buildings with offset floors work, where in one side of the building you can go up (naturally) a floor at a time, but on the other side all the levels are offset by a half a floor? Just to confuse things more, there's a building not too far away from where I am which has two "level 2" floors, that is, the elevator stops twice between floor 1 and floor 3 (they're called 2b and 2d - though I have not the vaguest idea what the 'b' and 'd' mean - 2d is above 2b). There needs to be more text describing just what floor numbers mean, and perhaps how the numbers are meant to be translated to and from the external designations that people use. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 11:31:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12765; Fri, 20 Jun 2003 11:31:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNqx-0005Zv-0F; Fri, 20 Jun 2003 11:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNqO-0005Om-2M for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 11:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12543 for ; Fri, 20 Jun 2003 11:30:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TNqN-0005Zy-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 11:30:27 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19TNqM-0005Z7-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 11:30:26 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5KFTrO1029480; Fri, 20 Jun 2003 11:29:54 -0400 (EDT) Received: from cisco.com ([161.44.65.124]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA20087; Fri, 20 Jun 2003 11:29:52 -0400 (EDT) Message-ID: <3EF32870.1040007@cisco.com> Date: Fri, 20 Jun 2003 11:29:52 -0400 From: Josh Littlefield User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms CC: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records References: <4.3.2.7.2.20030606002703.03d40c28@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph Droms wrote: > DDNS-DHCP issue: > > The interaction between DHCPv4 and DHCPv6 needs to be carefully > defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 > server updates the AAAA RR of the same node? How is the conflict > in the use of the DHCID RR for that node resolved? With the current definition of the DHCID RR and the proposed algorithm in draft-ietf-dhc-ddns-resolution-05.txt, there is clearly an issue to be resolved. The resolution could take the form of changing the DHCID RR definition to be v4-only, and adding a new DHCIDv6 RR for v6, or if could take the form of changing the algorithm in the dhc-ddns I-D. The issue is the algorithm's implicit expectation that just one DHCID RR will be present on a name. That may not be the case for a dual-stack client, where 2 different DHCID RRs would be generated. The implicit expectation that DHCID is effectively a singleton occurs in 2 places in the algorithm: 1) In 6.1 (Adding A RRs): The first update asserts the name does not exist. Failing that, the next update asserts the name exists with the expected DHCID. When this fails (as it will if a v6 DHCID is already there with now v4 DHCID), the entire update fails, concluding the name is in use by someone else. This second update will also fail if the anticipated v4 DHCID is already there, but a v6 DHCID is there as well. This is because DNS Update does not allow one to assert the presence of only one RR in an RR set. Instead, one must assert the entire RR set looks a certain way. So for this second update to succeed, it would need to include the v6 DHCID RR. 2) In 6.3 (Removing Entries): Again, an assertion problem with the DHCID (in the case of removing A/AAAA records). To succeed, the assertion would have to include all DHCID RRs on the name. In order to allow the coexistence of both v4 and v6 DHCID RRs on the same name, the algorithm would need change, to add additional steps, as follows: In 6.1, the last paragraph (before the DISCUSSION), on receiving NXRRSET to the second query (Update), the updater would then need to send a Query to learn the existing DHCID RR set on the name. The updater would then need to examine this DHCID RR set, and determine whether the update should, or should not occur. Most likely, the only case in which the update should occur is when the updater is able to determine that the existing DHCID RRs correspond to the same DHCP client. (This is not an easy determination to make if, for example, a v6 DHCID RR exists when making a v4 update, unless the updater generated the existing DHCID RR.) If it is determined by the updater that the update should proceed, the update sent should employ prerequisites asserting the state of the entire existing DHCID RR set. This is to ensure the RR set has not changed, since its state formed the basis for the update decision. A similar additional 2 steps (query and update) would need to be added to section 6.3 when removing A or AAAA RRs. I believe it may be acceptable to make these additional steps optional, at least in the forward (A, AAAA) update case. An v4 (or v6) updater who finds an existing v6 (or v4) DHCID RR may be unable to tell that the existing RR corresponds to the same client, since the RR data is a hash of something that updater doesn't know. So querying the existing DHCID RRs may provide no information to persuade the updater to update that name. By not implementing the additional algorithm steps, that updater would be implementing a strict policy of name segregation, which may be the best it can do. Clearly, an updater than can determine that v4 and v6 DHCID RRs correspond to the same client (most likely because it was the source of both) should implement the additional steps. There may be benefit to recommending (in a separate document?) that dual stack DHCP clients form DUIDs and client-IDs from the same data, to increase the likelihood that an updator would be able to predict the data of a v6 DHCID from a v4 DHCP packet, and vice versa. -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 12:26:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15949; Fri, 20 Jun 2003 12:26:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOi9-0001wS-AL; Fri, 20 Jun 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOht-0001wF-UE for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 12:25:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15908 for ; Fri, 20 Jun 2003 12:25:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TOhs-0006Pk-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 12:25:44 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19TOhs-0006Pb-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 12:25:44 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 09:27:04 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5KGPBUe027124; Fri, 20 Jun 2003 09:25:11 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.230]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD49281; Fri, 20 Jun 2003 12:25:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20030620110509.024bd830@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jun 2003 12:25:10 -0400 To: dhcwg@ietf.org From: Kim Kinnear Cc: kkinnear@cisco.com, rdroms@cisco.com, Richard_Woundy@cable.comcast.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] leasequery draft update Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, I have submitted a new update to the leasequery draft: draft-ietf-dhc-leasequery-05.txt This updates the current -04 version at ietf.org, and replaces an interim -05 version from dhcp.org (which didn't make the last deadline). I didn't bump the version beyond the interim version since that version never made it through the ietf.org process. Here is the list of the changes made since -04. #1 and #2 were available in the interim version, and #3 -> #6 were made since then. All of these changes were discussed at the last IETF meeting. ---------------- 1. Updated the leasequery draft to address the issues raised by Thomas Narten concerning the problem statement and how it relates to the actual protcol extension described in the draft. 2. I have changed the Abstract and the beginning of sections 1, 3, 4, and 5. The changes were restricted to the first few paragraphs of each numbered section. 3. Removed R bit and all reservations information. 4. Remove ability to get information about existing clients which don't have active leases. Changed the DHCPLEASEKNOWN message to return only information that this server knows about this IP address (so that the relay agent doesn't have to ask other servers). 5. Updated normative/informative. 6. Updated front matter to ensure it is about gleaning. ---------------- Cheers -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 14:27:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23159; Fri, 20 Jun 2003 14:27:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQbG-0001T6-E0; Fri, 20 Jun 2003 14:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQar-0001P7-KR for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 14:26:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22696; Fri, 20 Jun 2003 14:26:34 -0400 (EDT) Message-Id: <200306201826.OAA22696@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 14:26:33 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-pktc-kerb-tckt-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration Option Author(s) : P. Duffy Filename : draft-ietf-dhc-pktc-kerb-tckt-03.txt Pages : 7 Date : 2003-6-20 This document defines a new sub-option for the CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate locally persisted Kerberos tickets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pktc-kerb-tckt-03.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-pktc-kerb-tckt-03.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: <2003-6-20140115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pktc-kerb-tckt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140115.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 14:27:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23160; Fri, 20 Jun 2003 14:27:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQbG-0001Sy-1u; Fri, 20 Jun 2003 14:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQan-0001Ng-Jp for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 14:26:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22672; Fri, 20 Jun 2003 14:26:30 -0400 (EDT) Message-Id: <200306201826.OAA22672@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 14:26:29 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : DHCP Lease Query Author(s) : R. Woundy, K. Kinnear Filename : draft-ietf-dhc-leasequery-05.txt Pages : 27 Date : 2003-6-20 A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-leasequery-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-leasequery-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: <2003-6-20140104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-leasequery-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-leasequery-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140104.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 14:27:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23161; Fri, 20 Jun 2003 14:27:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQbG-0001Uw-Ui; Fri, 20 Jun 2003 14:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQaw-0001RY-2i for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 14:26:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22718; Fri, 20 Jun 2003 14:26:38 -0400 (EDT) Message-Id: <200306201826.OAA22718@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 14:26:38 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-07.txt,.pdf Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-07.txt,.pdf Pages : 13 Date : 2003-6-20 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-isnsoption-07.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-isnsoption-07.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: <2003-6-20140127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140127.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 14:56:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27695; Fri, 20 Jun 2003 14:56:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TR3J-000434-Cz; Fri, 20 Jun 2003 14:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TR3C-00042t-F4 for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 14:55:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27573; Fri, 20 Jun 2003 14:55:41 -0400 (EDT) Message-Id: <200306201855.OAA27573@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org, ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 14:55:39 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-07.txt,.pdf Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-07.txt,.pdf Pages : 13 Date : 2003-6-20 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-isnsoption-07.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-isnsoption-07.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: <2003-6-20140127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140127.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 15:46:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04661; Fri, 20 Jun 2003 15:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TRph-0006eL-3k; Fri, 20 Jun 2003 15:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TRol-0006Zn-1C for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 15:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04575 for ; Fri, 20 Jun 2003 15:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TRoj-0002NE-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 15:45:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19TRoi-0002LE-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 15:45:00 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2003 12:42:44 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5KJiQIX015271; Fri, 20 Jun 2003 12:44:27 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-260.cisco.com [10.82.241.4]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA18831; Fri, 20 Jun 2003 12:44:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20030620151602.0200e778@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jun 2003 15:44:23 -0400 To: Robert Elz From: John Schnizlein Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV Cc: dhcwg@ietf.org, geopriv@mail.apps.ietf.org In-Reply-To: <12617.1056112719@munnari.OZ.AU> References: <4.3.2.7.2.20030620061756.0468bf98@funnel.cisco.com> <4.3.2.7.2.20030620061756.0468bf98@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thank you for the probing questions. Clarification embedded in context: At 08:38 AM 6/20/2003, Robert Elz wrote: >The definitions of altitude in that draft need work. > >Metres (positive and negative) is simple enough, but relative to >what? Unless I missed it, I could find no definition of what is 0. Zero is defined by the datum, at least for those we know. To cover any cases where it is not, we propose clarifying text as follows: If MU = 1, an AltRes value 0 would indicate unknown altitude. The most precise Altitude would have an AltRes value of 30. Unless otherwise defined by datum, a value of 0 is with respect to mean-low-tide. >If the assumption is that it is to be "mean sea level" then which sea? >If it is to be above (+ or - below) ground level, which ground level >within the designated area given by the latitude and longitude (sloping >ground). It is our understanding that mean low tide is well defined, since political and personal land-ownership boundaries are based on it. The reason this is a twos-complement value is to cover below zero altitudes as well as above zero altitudes. We are not attempting to represent any slope of the ground. The altitude is that of a point within the horizontal resolution of the horizontal location values. >When measured in floors, the "0" means ground level is fine, but >how are floors counted? Is there some standard, or does anyone >count them however they like. Can one assume that if some device >is at altitude (as a floor) N, then something at N+2 will be two >floors up? If N==12? How do buildings with offset floors work, >where in one side of the building you can go up (naturally) a floor >at a time, but on the other side all the levels are offset by a >half a floor? Just to confuse things more, there's a building >not too far away from where I am which has two "level 2" floors, >that is, the elevator stops twice between floor 1 and floor 3 >(they're called 2b and 2d - though I have not the vaguest idea >what the 'b' and 'd' mean - 2d is above 2b). There needs to be >more text describing just what floor numbers mean, and perhaps how >the numbers are meant to be translated to and from the external >designations that people use. Yes, the text about what floor values mean was mistakenly dropped in the editing process. We had lovely arguments about it before resolving intermediate floors with the 8-bit fraction part of the 30-bit twos-complement value. Your observation that local customs sometimes include intermediate floors answers the question about interval scale: one cannot assume just N floors between values of the value that differ by N. Although not interval-scale, the value is monotone (ordinal-scale). We propose clarifying text for intermediate floors as follows: The values represented by this MU will be of local significance. Since buildings and floors can vary due to lack of common control, the values chosen to represent the characteristics of an individual building will be derived and agreed upon by the operator of the building and the intended users of the data. Attempting to standardize this type of function is beyond the scope this document. Sub-floors can be represented by non-integer values. Example (1): a mezzanine between floor 1 and floor 2 could be represented as a value=1.1. Example (2): two mezzanines between floor 4 and floor 5 could be represented as values=4.1 and 4.2 respectively. Floors located below ground level could be represented by negative values. Larger values represent floors that are above (higher in altitude) floors with lower values. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 16:09:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06022; Fri, 20 Jun 2003 16:09:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TSBw-0007nV-CK; Fri, 20 Jun 2003 16:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TRqq-0006o6-2O for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 15:47:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04726 for ; Fri, 20 Jun 2003 15:47:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TRqo-0002PJ-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 15:47:10 -0400 Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx with smtp (Exim 4.12) id 19TRqn-0002PE-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 15:47:10 -0400 Received: (qmail 50841 invoked by uid 1016); 20 Jun 2003 19:47:34 -0000 Date: 20 Jun 2003 19:47:34 -0000 Message-ID: <20030620194734.50840.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length References: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> <15427.1056102254@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , tinydns has supported time-to-die since version 0.85 in February 2000. It automatically reduces the TTL as the time-to-die approaches, and then eliminates the record. See http://cr.yp.to/djbdns/tinydns-data.html. The obsolete AXFR replication protocol is unable to copy time-to-die information. This is one of the many reasons that I recommend rsync for replication. See http://cr.yp.to/djbdns/tcp.html#intro-axfr. Client systems running the clueless ``nscd'' program will keep data for an hour no matter what the TTL says, but at least there's some limit. Perhaps nscd will be fixed someday. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 20 16:55:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08136; Fri, 20 Jun 2003 16:55:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TSuT-0001dk-Tk; Fri, 20 Jun 2003 16:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TStg-0001d0-63 for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 16:54:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08052 for ; Fri, 20 Jun 2003 16:54:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TSte-00039N-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 16:54:10 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19TStd-00039K-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 16:54:09 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 01E701B2003; Fri, 20 Jun 2003 15:52:27 -0500 (CDT) From: Ted Lemon To: "D. J. Bernstein" , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Date: Fri, 20 Jun 2003 10:54:05 -0500 User-Agent: KMail/1.5 References: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> <15427.1056102254@munnari.OZ.AU> <20030620194734.50840.qmail@cr.yp.to> In-Reply-To: <20030620194734.50840.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306201054.05150.mellon@nominum.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday 20 June 2003 14:47, D. J. Bernstein wrote: > tinydns has supported time-to-die since version 0.85 in February 2000. > It automatically reduces the TTL as the time-to-die approaches, and then > eliminates the record. See http://cr.yp.to/djbdns/tinydns-data.html. We discussed and rejected time-to-die as a solution to this problem a couple of meetings back (I think in Tokyo) because we were concerned that if you do something like this, the effect is going to be a refresh storm as the time to die gets closer. So I'm very interested to know that somebody has actually tried this experiment. What's your experience with this - do you have any measurements about what happens in practice as the time to die approaches? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 21 06:19:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05289; Sat, 21 Jun 2003 06:19:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TfSW-0004PY-Je; Sat, 21 Jun 2003 06:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TfRi-0004PL-Be for dhcwg@optimus.ietf.org; Sat, 21 Jun 2003 06:18:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05270 for ; Sat, 21 Jun 2003 06:18:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TfRe-0006rH-00 for dhcwg@ietf.org; Sat, 21 Jun 2003 06:18:06 -0400 Received: from ip26.coe.tnet.co.th ([203.146.155.26] helo=fuchsia.home) by ietf-mx with esmtp (Exim 4.12) id 19TfRc-0006rE-00 for dhcwg@ietf.org; Sat, 21 Jun 2003 06:18:05 -0400 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h5LAHTlw004432; Sat, 21 Jun 2003 17:17:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5LAGne12388; Sat, 21 Jun 2003 17:16:52 +0700 (ICT) From: Robert Elz To: John Schnizlein cc: dhcwg@ietf.org, geopriv@mail.apps.ietf.org Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV In-Reply-To: <4.3.2.7.2.20030620151602.0200e778@wells.cisco.com> References: <4.3.2.7.2.20030620151602.0200e778@wells.cisco.com> <4.3.2.7.2.20030620061756.0468bf98@funnel.cisco.com> <4.3.2.7.2.20030620061756.0468bf98@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jun 2003 17:16:49 +0700 Message-ID: <5733.1056190609@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Fri, 20 Jun 2003 15:44:23 -0400 From: John Schnizlein Message-ID: <4.3.2.7.2.20030620151602.0200e778@wells.cisco.com> | To cover any cases where it is not, we propose clarifying text as follows: | If MU = 1, an AltRes value 0 would indicate unknown altitude. That's fine, and a good idea. | The most precise Altitude would have an AltRes value of 30. | Unless otherwise defined by datum, a value of 0 is with respect | to mean-low-tide. | It is our understanding that mean low tide is well defined, since | political and personal land-ownership boundaries are based on it. In most places it is, but consider you're somewhere in the middle of Panama, which low tide do you consider, the Atlantic, or the Pacific? There's a considerable distance in height between the two. I'd be tempted to pick the mean earth radius, and define that as 0, except then heights would be meaningless just about everywhere when compared to normal usages (not above ground level, not mean low tide sea level, not ...). Good luck finding some way that defines 0 precisely. | The reason this is a twos-complement value is to cover below zero | altitudes as well as above zero altitudes. Yes, that was obvious (I didn't think I said anything to question that). | We are not attempting to represent any slope of the ground. The | altitude is that of a point within the horizontal resolution of the | horizontal location values. No, I didn't think you were - but because the 0 point wasn't specified anywhere that I could see (if it is there and I missed it, perhaps it needs better highlighting), one possible definition of 0 may have been "ground level at the latitude and longitude specified". That would be fine when all 34 bits of precision were used, but when things are being deliberately vague, there would be no particular 0 point in that case. But given that sea level is the intended 0, the point about slopes is completely irrelevant, and you can ignore it. | Yes, the text about what floor values mean was mistakenly dropped | in the editing process. | | We propose clarifying text for intermediate floors as follows: That looks fine, and is about what I expected would be the best choice. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 23 10:20:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22175; Mon, 23 Jun 2003 10:20:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USAr-0002gE-PV; Mon, 23 Jun 2003 10:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19US6i-0002Z8-S6 for dhcwg@optimus.ietf.org; Mon, 23 Jun 2003 10:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21993 for ; Mon, 23 Jun 2003 10:15:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19US6R-0002SR-00 for dhcwg@ietf.org; Mon, 23 Jun 2003 10:15:27 -0400 Received: from birch.ripe.net ([193.0.1.96]) by ietf-mx with esmtp (Exim 4.12) id 19US6G-0002SK-00 for dhcwg@ietf.org; Mon, 23 Jun 2003 10:15:16 -0400 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h5NEEJRT029442; Mon, 23 Jun 2003 16:14:19 +0200 Date: Mon, 23 Jun 2003 16:14:19 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org cc: dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <20030620224347.48646.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On 20 Jun 2003, D. J. Bernstein wrote: > Ted Lemon writes: > > What's your experience with this - do you have any measurements about what > > happens in practice as the time to die approaches? > > Clients throw the record away shortly after the time-to-die, and ask for > new data when they need it, exactly as desired. So far, its server-specific, and the information about the exact time for ttd to take effect isn't transferrable via AXFR ( which can only transfer offsets via TTL ). What do clients see from tinydns? Eg, for a record of 'dying.example.com' which should expire at T+1500, would it be: Client A requesting 'dying.example.com' at time T receives: dying.example.com 1500 IN A 192.168.1.2 Client B requesting 'dying.example.com' at time T+100 receives: dying.example.com 1400 IN A 192.168.1.2 ? So, Client A and Client B have _nearly_ the same RR set, just with different TTLs. The end effect is that both Client A and Client B will drop the record from their cache at the appropriate time. This is good, right? So, the next question is, since Client A and Client B received different (authoritative) responses, does that mean that there were different versions of the zone 'example.com' at time T and T+100 ? If yes, there were different versions of the zone at T and T+100, then the SOA serial needs to be updated, with the consequent flurry of AXFR requests from the 'example.com' slaves when they noticed the SOA having changed. If no, there were not different versions of the zone (and no SOA serial change) at T and T+100, then we run into problems with the 'example.com' slaves giving different TTL values for 'dying.example.com' depending on when they retrieved the zone. ( This space left blank for an 'AXFR is bad, use rsync' comment ) > > we were concerned that if you do something like this, the effect is > > going to be a refresh storm as the time to die gets closer > > Please define ``refresh storm.'' Do you describe TTL-0 records as > causing ``refresh storms''? Section 3.4.2 of Vixies 1996 draft (related to implementation of time-to-die) has the wording: 3.4.2 - TTL Half Life Each time an RR's expiry reaches half of its previous value, that RR's TTL will be reduced to half of its previous value, until the TTL reaches a value less than or equal to sixty (60), i.e., one minute of real time, Whenever the TTL is automatically reduced by this process, the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). You could probably do wording such that the only time an SOA serial change occurs (due to TTL/TTD behaviour) is when an SOA request comes in (so the version of the zone on your non-time-to-die-internal-magic slave is correct), but you've still got the problem of differing clients getting differing versions of RRs in the zone without SOA serial change, which is not a good precedent. --==-- Bruce. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 23 10:22:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22264; Mon, 23 Jun 2003 10:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USCn-0002nm-72; Mon, 23 Jun 2003 10:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TnTR-0005ya-N8 for dhcwg@optimus.ietf.org; Sat, 21 Jun 2003 14:52:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12492 for ; Sat, 21 Jun 2003 14:52:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TnTO-0000af-00 for dhcwg@ietf.org; Sat, 21 Jun 2003 14:52:26 -0400 Received: from relais.videotron.ca ([24.201.245.36] helo=VL-MS-MR002.sc1.videotron.ca) by ietf-mx with esmtp (Exim 4.12) id 19TnTO-0000ac-00 for dhcwg@ietf.org; Sat, 21 Jun 2003 14:52:26 -0400 Received: from inungs1pjm7ehu ([24.203.55.159]) by VL-MS-MR002.sc1.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HGU00A9QHMM38@VL-MS-MR002.sc1.videotron.ca> for dhcwg@ietf.org; Sat, 21 Jun 2003 14:49:34 -0400 (EDT) Date: Sat, 21 Jun 2003 14:48:33 -0400 From: Inung Huang To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_48IuKq/AHvZJbnpvV8iZZg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [dhcwg] DHCP register IP, but my machine does not register IP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_48IuKq/AHvZJbnpvV8iZZg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi All: My machine does not register IP address automatically. Every time DHCP assignees me a new IP then my machine lost the IP. I have to reboot my computer to re register IP. I would like to know more about how it works and try to figure out what happen to may machine or my ISP DHCP server does not give me IP. Any information is appreciated. Inung Huang http://pages.infinit.net/inungh/ --Boundary_(ID_48IuKq/AHvZJbnpvV8iZZg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message
Hi All:
 
   My machine does not register IP address automatically.
   Every time DHCP assignees me a new IP then my machine lost the IP. I have to reboot my computer to re register IP.
   I would like to know more about how it works and try to figure out what happen to may machine or my ISP DHCP server does not give me IP.
   Any information is appreciated.
   
 
--Boundary_(ID_48IuKq/AHvZJbnpvV8iZZg)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 23 10:22:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22263; Mon, 23 Jun 2003 10:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USCm-0002ne-SQ; Mon, 23 Jun 2003 10:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TUbL-00087j-0n for dhcwg@optimus.ietf.org; Fri, 20 Jun 2003 18:43:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13378 for ; Fri, 20 Jun 2003 18:43:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TUbI-00043G-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 18:43:20 -0400 Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx with smtp (Exim 4.12) id 19TUbH-00043D-00 for dhcwg@ietf.org; Fri, 20 Jun 2003 18:43:19 -0400 Received: (qmail 48647 invoked by uid 1016); 20 Jun 2003 22:43:47 -0000 Date: 20 Jun 2003 22:43:47 -0000 Message-ID: <20030620224347.48646.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length References: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> <15427.1056102254@munnari.OZ.AU> <20030620194734.50840.qmail@cr.yp.to> <200306201054.05150.mellon@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ted Lemon writes: > What's your experience with this - do you have any measurements about what > happens in practice as the time to die approaches? Clients throw the record away shortly after the time-to-die, and ask for new data when they need it, exactly as desired. Exception: some broken programs like nscd keep the record for a while. The overall effect is similar to what happens when you manually set a low TTL. The advantage is that setting a time-to-die allows extra caching before the time-to-die; a low TTL doesn't. (There's also a user-interface advantage of scheduling the change in advance, but this isn't a protocol issue.) > we were concerned that if you do something like this, the effect is > going to be a refresh storm as the time to die gets closer Please define ``refresh storm.'' Do you describe TTL-0 records as causing ``refresh storms''? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 23 13:47:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00777; Mon, 23 Jun 2003 13:47:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVPB-0004ZJ-Cs; Mon, 23 Jun 2003 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USw8-0004iT-Gb for dhcwg@optimus.ietf.org; Mon, 23 Jun 2003 11:08:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23883 for ; Mon, 23 Jun 2003 11:08:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19USw5-0002pS-00 for dhcwg@ietf.org; Mon, 23 Jun 2003 11:08:49 -0400 Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx with smtp (Exim 4.12) id 19USvu-0002pP-00 for dhcwg@ietf.org; Mon, 23 Jun 2003 11:08:38 -0400 Received: (qmail 48341 invoked by uid 1016); 23 Jun 2003 15:09:05 -0000 Date: 23 Jun 2003 15:09:05 -0000 Message-ID: <20030623150905.48340.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length References: <20030620224347.48646.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bruce Campbell writes: > So, the next question is, since Client A and Client B received different > (authoritative) responses, does that mean that there were different > versions of the zone 'example.com' at time T and T+100 ? Of course not; that would be silly. The TTD---which is what caches actually store anyway---is the same. Queries at different times will interpret the same TTD as different TTLs, of course, but that doesn't mean the zone has changed. If you insist on corrupting the zone by retrieving it through AXFR, you'll get 2-second TTLs from my AXFR server. Of course, the record also won't disappear until the next AXFR. The effects on the secondary, and on clients talking to the secondary, are the same as if you had manually set a 2-second TTL in the first place. If you transfer the zone accurately (for example, through rsync), the secondary will allow more caching before the time-to-die than it would have with a 2-second TTL, and it will remove the record at exactly the right time without another transfer. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 23 13:47:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00776; Mon, 23 Jun 2003 13:47:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVPB-0004ZR-Nz; Mon, 23 Jun 2003 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVJw-0004R5-BM for dhcwg@optimus.ietf.org; Mon, 23 Jun 2003 13:41:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00355 for ; Mon, 23 Jun 2003 13:41:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVJf-0004Bu-00 for dhcwg@ietf.org; Mon, 23 Jun 2003 13:41:19 -0400 Received: from sa.vix.com ([204.152.187.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVJU-0004Bl-00 for dhcwg@ietf.org; Mon, 23 Jun 2003 13:41:08 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B97901396A; Mon, 23 Jun 2003 17:40:16 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: Message from Bruce Campbell of "Mon, 23 Jun 2003 16:14:19 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 23 Jun 2003 17:40:16 +0000 Message-Id: <20030623174016.B97901396A@sa.vix.com> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , [robert campbell] > What do clients see from tinydns? Eg, for a record of 'dying.example.com' > which should expire at T+1500, would it be: > > Client A requesting 'dying.example.com' at time T receives: > dying.example.com 1500 IN A 192.168.1.2 > > Client B requesting 'dying.example.com' at time T+100 receives: > dying.example.com 1400 IN A 192.168.1.2 > > ? > > So, Client A and Client B have _nearly_ the same RR set, just with > different TTLs. no. ttl does not affect rrset identity. per [rfc2136 1.1.1] et al. > The end effect is that both Client A and Client B will drop the record > from their cache at the appropriate time. This is good, right? yes. > So, the next question is, since Client A and Client B received different > (authoritative) responses, does that mean that there were different > versions of the zone 'example.com' at time T and T+100 ? no. see above. > If yes, there were different versions of the zone at T and T+100, then > the SOA serial needs to be updated, with the consequent flurry of AXFR > requests from the 'example.com' slaves when they noticed the SOA > having changed. no. any authoritative server could clamp its ttl's for local policy reasons without affecting zone identity. they can't be made longer but they could absolutely be made shorter without invalidating the zone soa:content mapping. > Section 3.4.2 of Vixies 1996 draft (related to implementation of > time-to-die) has the wording: > > 3.4.2 - TTL Half Life > > Each time an RR's expiry reaches half of its previous value, that RR's > TTL will be reduced to half of its previous value, until the TTL reaches > a value less than or equal to sixty (60), i.e., one minute of real time, > > > > Whenever the TTL is automatically reduced by this process, the zone will > be considered ``changed'' for the purpose of automatic SOA SERIAL > increment (see [UPDATE 3.6]) and real time zone slave notification (see > [NOTIFY]). > > You could probably do wording such that the only time an SOA serial change > occurs (due to TTL/TTD behaviour) is when an SOA request comes in (so the > version of the zone on your non-time-to-die-internal-magic slave is > correct), but you've still got the problem of differing clients getting > differing versions of RRs ... they aren't differing versions of rr's. ttl is not considered in rr comparisons. > ... in the zone without SOA serial change, which is not a good precedent. see also [rfc2136 3.6]. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 24 06:35:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09900; Tue, 24 Jun 2003 06:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ul8f-0004IH-7G; Tue, 24 Jun 2003 06:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ul88-0004HX-2S for dhcwg@optimus.ietf.org; Tue, 24 Jun 2003 06:34:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09537; Tue, 24 Jun 2003 06:29:42 -0400 (EDT) Message-Id: <200306241029.GAA09537@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: pana@research.telcordia.com, dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 24 Jun 2003 06:29:41 -0400 Subject: [dhcwg] I-D ACTION:draft-tschofenig-pana-bootstrap-rfc3118-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Bootstrapping RFC3118 Delayed authentication using PANA Author(s) : H. Tschofenig et al. Filename : draft-tschofenig-pana-bootstrap-rfc3118-00.txt Pages : 19 Date : 2003-6-23 PANA provides network access authentication and uses the Extensible Authentication Protocol (EAP) to carry different authentication methods. The combination of EAP with an AAA architecture allows authentication and authorization of a roaming user to an access network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-pana-bootstrap-rfc3118-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tschofenig-pana-bootstrap-rfc3118-00.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-tschofenig-pana-bootstrap-rfc3118-00.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: <2003-6-23141923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tschofenig-pana-bootstrap-rfc3118-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tschofenig-pana-bootstrap-rfc3118-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-23141923.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 24 12:05:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21706; Tue, 24 Jun 2003 12:05:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqI1-0000OH-Qi; Tue, 24 Jun 2003 12:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqHX-0000Mr-Rv for dhcwg@optimus.ietf.org; Tue, 24 Jun 2003 12:04:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21597 for ; Tue, 24 Jun 2003 12:02:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UqFN-0003ui-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 12:02:17 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19UqEx-0003u2-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 12:01:54 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5OG0Uxe269360 for ; Tue, 24 Jun 2003 12:00:30 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-226-238.mts.ibm.com [9.65.226.238]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5OG0SGA121540 for ; Tue, 24 Jun 2003 10:00:29 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h5OFxVK02817 for ; Tue, 24 Jun 2003 11:59:31 -0400 Message-Id: <200306241559.h5OFxVK02817@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Date: Tue, 24 Jun 2003 11:59:30 -0400 From: Thomas Narten Subject: [dhcwg] AD review of draft-ietf-dhc-unused-optioncodes-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The WG has asked that this document be advanced as an informational RFC. Seems like an IETF Last Call on this document would be appropriate, since the point is (in some sense) to verify that it is OK to reuse the listed options for something else. Right? My comments (all nits, I think). > Unused DHCP Option Codes A more descriptive title might be better? E.g.: Reclaiming Unused DHCP Option Codes for Reassignment for Future DHCP Options. (or something similar) > The following option codes are used in the "Preboot Execution > Environment (PXE) Specification, Version 2.1" [4]. However, although > these options are in widespread use by devices that use PXE, none of > these option codes have been specified as a Standards-track RFC. remove mention of standards track (since this is not required?) I.e., just getting them published as RFCs would be good.. > 3.1 Client System > > Code: 93 > > Name: Client System > > Defined in: (none) Shouldn't you reference the PXE documents here? (ditto for remaining PXE ones). Also, including the contact information in the option description struck me a bit odd. As I was reading this, my first thought was "has this person been contacted, and what did they say?" The document could include an indication of this. > Normative References Hmm. Aren't all of the references actually informative? Which ones are critical to *this* document? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 24 13:10:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24630; Tue, 24 Jun 2003 13:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UrIw-00042U-EO; Tue, 24 Jun 2003 13:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Um2D-00076w-Kr for dhcwg@optimus.ietf.org; Tue, 24 Jun 2003 07:32:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12293 for ; Tue, 24 Jun 2003 07:32:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Um1x-0002IS-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 07:32:09 -0400 Received: from birch.ripe.net ([193.0.1.96]) by ietf-mx with esmtp (Exim 4.12) id 19Um1m-0002HD-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 07:31:59 -0400 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h5OBTKRT004063; Tue, 24 Jun 2003 13:29:20 +0200 Date: Tue, 24 Jun 2003 13:29:20 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org cc: dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <20030623174016.B97901396A@sa.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , [ TTD for clients ] On Mon, 23 Jun 2003, David Vixie wrote: > [robert campbell] > > What do clients see from tinydns? Eg, for a record of 'dying.example.com' > > which should expire at T+1500, would it be: > > > > So, Client A and Client B have _nearly_ the same RR set, just with > > different TTLs. > > no. ttl does not affect rrset identity. per [rfc2136 1.1.1] et al. Right. So it would be easy to implement TTD inside a nameserver (ref tinnydns), and provide records to clients with appropriate TTLs without fear of increasing traffic abnormally (the clients won't come back until the record expires), and, theres no protocol change involved. End of argument as far as DNSEXT is concerned. [ propagating TTD information to slaves ] Paul Bernstein wrote: > If you insist on corrupting the zone by retrieving it through AXFR, > you'll get 2-second TTLs from my AXFR server. Of course, the record also > won't disappear until the next AXFR. The effects on the secondary, and > on clients talking to the secondary, are the same as if you had manually > set a 2-second TTL in the first place. So... if a record is due to expire in 1500 seconds, and you know that the slave 'should' transfer the zone again via axfr in 1300 seconds (via SOA values), you will merrily supply a 2 second TTL on said records, thus causing the slave to incur unneeded traffic from clients who effectively cannot cache the record at all and must requery for the record each time they want it. ( For instance, someone taking 3 seconds to reach a web page and clicking on the 'Next' link, resulting in the record being looked up again ) Of course, you'd argue that its because the slaves are using an outdated protocol, but it strikes me that you've coded your nameserver to be intentionally irritating. 'Wow'. Supplying TTLs for expiring records based on the SOA TTL/etc values (with dropping back to 2 second TTLs for those records which should be expired before the slaves next refresh themselves) would be more sensible. Still, when new records are created, you have to propagate the information outwards. Rsync, AXFR and IXFR are all unsuitable for this in a frequently changing environment due to their associated overhead. Dynamic updates sent from the master to each slave are more prompt, although you still have the housekeeping of removing the records once they should have expired (in the absence of remove-after values being able to be sent), and liable to be lost (but will get picked up on the next zone transfer). Wait, aren't we back at the start again? --==-- Bruce. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 24 13:10:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24628; Tue, 24 Jun 2003 13:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UrIv-00041q-Qq; Tue, 24 Jun 2003 13:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqRn-0001Vg-J9 for dhcwg@optimus.ietf.org; Tue, 24 Jun 2003 12:15:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22145 for ; Tue, 24 Jun 2003 12:14:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UqRS-00041W-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 12:14:46 -0400 Received: from sa.vix.com ([204.152.187.1]) by ietf-mx with esmtp (Exim 4.12) id 19UqRH-000401-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 12:14:35 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DFAD313968; Tue, 24 Jun 2003 16:13:10 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: Message from Bruce Campbell of "Tue, 24 Jun 2003 13:29:20 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 24 Jun 2003 16:13:10 +0000 Message-Id: <20030624161310.DFAD313968@sa.vix.com> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Still, when new records are created, you have to propagate the > information outwards. Rsync, AXFR and IXFR are all unsuitable for > this in a frequently changing environment due to their associated > overhead. ... "sez you." before it was called dnsext, this wg was called dnsind. that stood for Incrementalzonetransfer, Notificationofchanges, and Dynamicupdate; these were the three features that the powers that were decided were needed in order to support DHCP and IPv6, which were the New things in ~1994. the architectural paradigm was to use Update to get things into the master, Notify to make the slaves aware of these new changes without waiting for an SOA timer to expire, and IXFR to get these changes distributed to the slaves without having to transfer all the unchanged data as well. interestingly, ohta-san preferred a different, masterless model, but he still did IXFR when consensus went in favour of the i-n-d model. also interesting was microsoft, who went for a masterless model using non-DNS channels for synchronization (but they never did implement healing after a partition event.) now as to performance. a company who was bundling BIND8 into a dhcp/dns integration product stress tested the i-n-d model, and found all kinds of early (pre-Y2K) data corruption bugs in our IXFR implementation. their goal was to be able to shoot thousands of DHCP-originated PTR updates per second through BIND8 and have the slaves remain synchronized -- and it all works fine. therefore i dispute ("sez you") your assertion of "unsuitable". various other commercial entities, mostly non-BIND based, have also reached these transaction volumes, using the i-n-d model. you may not think it's pretty, but noone has yet found a real world workload that the model can't address if you use the right hardware and software to support the load. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 24 14:21:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29689; Tue, 24 Jun 2003 14:21:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UsPc-0007He-Pi; Tue, 24 Jun 2003 14:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UsP3-0007Fb-0U for dhcwg@optimus.ietf.org; Tue, 24 Jun 2003 14:20:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29518 for ; Tue, 24 Jun 2003 14:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UsP0-0005RU-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 14:20:22 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 19UsOe-0005R3-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 14:20:00 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5OIIDkj291348 for ; Tue, 24 Jun 2003 14:18:13 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-226-238.mts.ibm.com [9.65.226.238]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5OIICGA098634 for ; Tue, 24 Jun 2003 12:18:13 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h5OIHGt11080 for ; Tue, 24 Jun 2003 14:17:16 -0400 Message-Id: <200306241817.h5OIHGt11080@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Date: Tue, 24 Jun 2003 14:17:16 -0400 From: Thomas Narten Subject: [dhcwg] AD review of draft-ietf-dhc-relay-agent-auth-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The WG has requested publication of this document as a PS. My review comments: High-level comments: This document contains two logically separate documents, an IPSec-based solution and one that uses the Relay Agent option. I think it would be better to have the two approaches documented in separate IDs (with a non-normative cross pointer to the other). This will help in the future when it becomes time to advance (or retire) one of them, etc. Plus, by being together, issues on one technique will block publication of both schemes. I'll note that the description of the IPSec approach is very skimpy. I predict that a review from an IPsec person will request that more details be added... Second, I'm confused about the Relay Indentifier field, when it is needed (and why). It kind of seems to me that its needed to identify which relay agent added a particular set of relay agent options, but in that case, this isn't an authentication-specfic issue and would perhaps better be handeled in a way that isn't specific to the authentication suboption. (i.e, so it could also be used if the authentication suboption is not present). > The Relay Identifier field is used by relay agents that do not set > giaddr, as described in RFC 3046 [2], Section 2.1. I reread this section, and didn't feel like I completely understood... There are times when a relay agent just adds more suboptions to an existing relay-agent option, rather than appending a new set? That makes it harder to identify who inserted what option... This is even worse when one node signs (cryptographicall) information provided by another, and the "trust" is not based on strong crypto... > selects an appropriate Replay Detection value. The sender places its > identifier into the Relay ID field, if necessary, or sets the field > to all zeroes. The sender sets the suboption length, places the Why not just always include it, since the field is there anyway... That would seem to simplify things... Nits below. > and servers to autenticate the identity of the source and contents of typo > Four bits are reserved for future use. These bits SHOULD be set to > zero, and MUST be ignored when the suboption is processed. Not quite true, as the integrity check includes them? Reword? > 4.2 Replay Detection > > The replay-detection mechanism is based on the notion that a receiver > can determine whether or not a message has a valid replay token > value. The default RDM, with value 1, specifies that the Replay > Detection field contains an increasing counter value. The receiver > associates a replay counter with each sender, and rejects any message > containing an authentication suboption with a Replay Detection > counter value less than the last valid value. DHCP servers MAY > identify relay agents by giaddr value or by other data in the message > (e.g. data in other relay agent suboptions). Relay agents identify > less than, or less than or equal? > the its notion of the last valid replay counter value associated with s/the its/its/ > The Key ID exists only to allow the sender and receiver to specify a > shared secret in cases where more than one secret is in use among a > network's relays and DHCP servers. The Key ID values are entirely a > matter of local configuration; they only need to be locally unique. > This specification does not define any semantics or impose any > requirements on this algorithm's Key ID values. name space could be clearer. Would it be better to just say the combination of relay id/key ID is unique? or something else? Or is it really intended that IDs are a flat space for the entire site? > should expect an Authentication suboption. The receiver MAY be > configured to drop incoming messages that do not contain a valid > relay agent information option and Authentication suboption. better: MUST support configuration that allows ... NOte: since the signature is at the end of the option, wouldn't it be better to have the integrity check be performed up to the signature, but exclude it? What is the value in setting it to zero an including it in the check? > Use of the authentication suboption SHOULD be disabled by default. Seems unnecessary. How can the suboption be used in the absence of keying info, which needs to be manually configured? > 4.7.1 Receiving Messages from Other Relay Agents > > There are network configurations in which one relay agent adds the > relay agent option, and then forwards the DHCP message to another > relay. For example, a layer-2 switch might be directly connected to > a client, and it might forward messages to an aggregating router, > which sets giaddr and then forwards the message to a DHCP server. > When a DHCP relay which implements the Authentication suboption > receives a message, it MAY use the procedures in Section 4.6 to > verify the source of the message before forwarding it. Example could be better. An L2 switch presumably is not a relay agent... Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 25 11:02:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13687; Wed, 25 Jun 2003 11:02:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBma-0006OQ-LA; Wed, 25 Jun 2003 11:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtRs-0002Va-DQ for dhcwg@optimus.ietf.org; Tue, 24 Jun 2003 15:27:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06047 for ; Tue, 24 Jun 2003 15:27:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtRc-0006LN-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 15:27:08 -0400 Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx with smtp (Exim 4.12) id 19UtRQ-0006L3-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 15:26:57 -0400 Received: (qmail 79373 invoked by uid 1016); 24 Jun 2003 19:26:53 -0000 Date: 24 Jun 2003 19:26:53 -0000 Message-ID: <20030624192653.79372.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length References: <20030623174016.B97901396A@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bruce Campbell writes: > So... if a record is due to expire in 1500 seconds, and you know that the > slave 'should' transfer the zone again via axfr in 1300 seconds (via SOA > values), you will merrily supply a 2 second TTL on said records Correct. Yes, short TTLs cause minor increases in the frequency of DNS lookups, but long TTLs cause administrative headaches. If the next AXFR is delayed, the old data will stick around longer than it should. > Still, when new records are created, you have to propagate the information > outwards. Rsync, AXFR and IXFR are all unsuitable for this in a > frequently changing environment due to their associated overhead. Actually, rsync and tinydns-data can make any number of updates to a multiple-megabyte database in well under a second on a typical computer. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 25 14:58:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25439; Wed, 25 Jun 2003 14:58:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFSy-0001x3-VM; Wed, 25 Jun 2003 14:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFSd-0001wI-OP for dhcwg@optimus.ietf.org; Wed, 25 Jun 2003 14:57:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25403; Wed, 25 Jun 2003 14:57:35 -0400 (EDT) Message-Id: <200306251857.OAA25403@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , dhcwg@ietf.org From: The IESG Date: Wed, 25 Jun 2003 14:57:35 -0400 Subject: [dhcwg] Protocol Action: Security Ticket Control Sub-option for the CableLabs Client Configuration Option to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Security Ticket Control Sub-option for the CableLabs Client Configuration Option' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. Technical Summary This document defines a new sub-option for the CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate locally persisted security tickets. Working Group Summary There was WG consensus to advance the document. Protocol Quality The specification has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 26 11:00:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29486; Thu, 26 Jun 2003 11:00:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYEE-0006xW-Cm; Thu, 26 Jun 2003 11:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VXuk-0005Nw-2x for dhcwg@optimus.ietf.org; Thu, 26 Jun 2003 10:39:54 -0400 Received: from linux.interlinx.bc.ca (ik-dynamic-66-102-65-64.kingston.net [66.102.65.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28356 for ; Thu, 26 Jun 2003 10:38:29 -0400 (EDT) Received: from pc (pc [10.75.22.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by linux.interlinx.bc.ca (Postfix) with ESMTP id 6443C1274 for ; Thu, 26 Jun 2003 10:20:37 -0400 (EDT) Subject: [dhcwg] WG last call on draft-ietf-dhc-server-mib-08 (2nd last call) From: "Brian J. Murrell" To: dhcwg@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XI1usVm6viRErCQjn3Eo" Message-Id: <1056637236.22639.52.camel@pc> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0-1mdk Date: 26 Jun 2003 10:20:37 -0400 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --=-XI1usVm6viRErCQjn3Eo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This draft looks good to me. I think it should move forward. b. --=20 Brian J. Murrell --=-XI1usVm6viRErCQjn3Eo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA++wE0l3EQlGLyuXARApXfAKDUb+Uy5E0lEhywbWYq+iz+2kqB4ACgsOsV dmZwqN4IPOt0ms87WpnTMK8= =tMhl -----END PGP SIGNATURE----- --=-XI1usVm6viRErCQjn3Eo-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 27 14:24:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09602; Fri, 27 Jun 2003 14:24:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxrm-0005KC-Pz; Fri, 27 Jun 2003 14:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuP1-0002NW-VS for dhcwg@optimus.ietf.org; Fri, 27 Jun 2003 10:40:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28354; Fri, 27 Jun 2003 10:12:19 -0400 (EDT) Message-Id: <200306271412.KAA28354@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 27 Jun 2003 10:12:18 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-sigzero-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : DHCP RSA/DSA Authentication using DNS KEY records Author(s) : T. Lemon, M. Richardson Filename : draft-ietf-dhc-auth-sigzero-00.txt Pages : 0 Date : 2003-6-26 This document defines a method for using a KEY record in the DNS belonging to a particular host to authenticate that host's DHCP transactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-sigzero-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sigzero-00.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-sigzero-00.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: <2003-6-27081144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-sigzero-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-sigzero-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27081144.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 27 14:28:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10085; Fri, 27 Jun 2003 14:28:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxwu-0007SL-Kg; Fri, 27 Jun 2003 14:27:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuQT-0002P9-K6 for dhcwg@optimus.ietf.org; Fri, 27 Jun 2003 10:43:14 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22628 for ; Fri, 27 Jun 2003 07:47:34 -0400 (EDT) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5RAibVI021361; Fri, 27 Jun 2003 12:44:38 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E2C2282231; Fri, 27 Jun 2003 12:28:54 +0200 (CEST) Message-ID: <3EFC2001.3010902@ccrle.nec.de> Date: Fri, 27 Jun 2003 12:44:17 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Interop Vienna: New Information Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, everybody who is interested in the DHCPv6 interoperability test in Vienna may be interested in the update web page. The registration is now open and some administration issues have been updated: http://www.dhcpv6.org/events.htm Cheers Martin _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 27 14:52:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13040; Fri, 27 Jun 2003 14:52:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VyKI-0007MI-CV; Fri, 27 Jun 2003 14:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VyJn-0007Hb-Gy for dhcwg@optimus.ietf.org; Fri, 27 Jun 2003 14:51:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13000 for ; Fri, 27 Jun 2003 14:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VyJn-0005Hr-00 for dhcwg@ietf.org; Fri, 27 Jun 2003 14:51:31 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19VyJc-0005Gz-00 for dhcwg@ietf.org; Fri, 27 Jun 2003 14:51:20 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2003 11:42:32 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5RIefMO025079; Fri, 27 Jun 2003 11:40:43 -0700 (PDT) Received: from rdroms-w2k.cisco.com ([161.44.65.118]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAG85916; Fri, 27 Jun 2003 14:40:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030625173824.00bbd0f8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Jun 2003 14:38:12 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] AD review of draft-ietf-dhc-relay-agent-auth-01.txt Cc: mjs@cisco.com, dhcwg@ietf.org In-Reply-To: <200306241817.h5OIHGt11080@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thomas, The two techniques in this document both address the same problem: the authentication of messages exchanged between DHCP relay agents and DHCP servers. The title of the document should, perhaps, read "Authentication of DHCP Message Exchanged Between Relay Agents and Servers". The two techniques for authentication are described in a single document because they are applicable in different scenarios. Prior to the last dhc WG meeting, you had asked for a comparison of the two techniques, which John Schnizlein published on the dhc WG mailing list. Based on that comparison, the consensus of the WG was that the two techniques should be advanced together, because neither was appropriate for all operational scenarios. At the dhc WG meeting in San Francisco we agreed to advance the two techniques in a single document. The description of the use of IPsec for authentication was copied from an earlier draft of the DHCPv6 specification. The text in draft-ietf-dhc-relay-agent-auth-01.txt is the same as in the version of the DHCPv6 specification that has been accepted as a Proposed Standard. The more detailed list of rules in the DHCPv6 specification will be used as the basis to provide additional detail in this document. Mark will respond to your comments specific to the relay agent option definition. - Ralph At 02:17 PM 6/24/2003 -0400, Thomas Narten wrote: >The WG has requested publication of this document as a PS. My review >comments: > >High-level comments: > >This document contains two logically separate documents, an >IPSec-based solution and one that uses the Relay Agent option. I think >it would be better to have the two approaches documented in separate >IDs (with a non-normative cross pointer to the other). This will help >in the future when it becomes time to advance (or retire) one of them, >etc. Plus, by being together, issues on one technique will block >publication of both schemes. I'll note that the description of the >IPSec approach is very skimpy. I predict that a review from an IPsec >person will request that more details be added... > >Second, I'm confused about the Relay Indentifier field, when it is >needed (and why). It kind of seems to me that its needed to identify >which relay agent added a particular set of relay agent options, but >in that case, this isn't an authentication-specfic issue and would >perhaps better be handeled in a way that isn't specific to the >authentication suboption. (i.e, so it could also be used if the >authentication suboption is not present). > > > The Relay Identifier field is used by relay agents that do not set > > giaddr, as described in RFC 3046 [2], Section 2.1. > >I reread this section, and didn't feel like I completely understood... > >There are times when a relay agent just adds more suboptions to an >existing relay-agent option, rather than appending a new set? That >makes it harder to identify who inserted what option... This is even >worse when one node signs (cryptographicall) information provided by >another, and the "trust" is not based on strong crypto... > > > selects an appropriate Replay Detection value. The sender places its > > identifier into the Relay ID field, if necessary, or sets the field > > to all zeroes. The sender sets the suboption length, places the > >Why not just always include it, since the field is there anyway... >That would seem to simplify things... > >Nits below. > > > and servers to autenticate the identity of the source and contents of > >typo > > > Four bits are reserved for future use. These bits SHOULD be set to > > zero, and MUST be ignored when the suboption is processed. > >Not quite true, as the integrity check includes them? Reword? > > > 4.2 Replay Detection > > > > The replay-detection mechanism is based on the notion that a receiver > > can determine whether or not a message has a valid replay token > > value. The default RDM, with value 1, specifies that the Replay > > Detection field contains an increasing counter value. The receiver > > associates a replay counter with each sender, and rejects any message > > containing an authentication suboption with a Replay Detection > > counter value less than the last valid value. DHCP servers MAY > > identify relay agents by giaddr value or by other data in the message > > (e.g. data in other relay agent suboptions). Relay agents identify > > > >less than, or less than or equal? > > > the its notion of the last valid replay counter value associated with > >s/the its/its/ > > > The Key ID exists only to allow the sender and receiver to specify a > > shared secret in cases where more than one secret is in use among a > > network's relays and DHCP servers. The Key ID values are entirely a > > matter of local configuration; they only need to be locally unique. > > This specification does not define any semantics or impose any > > requirements on this algorithm's Key ID values. > >name space could be clearer. Would it be better to just say the >combination of relay id/key ID is unique? or something else? Or is it >really intended that IDs are a flat space for the entire site? > > > should expect an Authentication suboption. The receiver MAY be > > configured to drop incoming messages that do not contain a valid > > relay agent information option and Authentication suboption. > >better: MUST support configuration that allows ... > >NOte: since the signature is at the end of the option, wouldn't it be >better to have the integrity check be performed up to the signature, >but exclude it? What is the value in setting it to zero an including >it in the check? > > > Use of the authentication suboption SHOULD be disabled by default. > >Seems unnecessary. How can the suboption be used in the absence of >keying info, which needs to be manually configured? > > > 4.7.1 Receiving Messages from Other Relay Agents > > > > There are network configurations in which one relay agent adds the > > relay agent option, and then forwards the DHCP message to another > > relay. For example, a layer-2 switch might be directly connected to > > a client, and it might forward messages to an aggregating router, > > which sets giaddr and then forwards the message to a DHCP server. > > When a DHCP relay which implements the Authentication suboption > > receives a message, it MAY use the procedures in Section 4.6 to > > verify the source of the message before forwarding it. > >Example could be better. An L2 switch presumably is not a relay >agent... > >Thomas > >_______________________________________________ >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-admin@ietf.org Fri Jun 27 16:18:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18859; Fri, 27 Jun 2003 16:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VzfV-0006qg-JM; Fri, 27 Jun 2003 16:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VzeZ-0006fy-Gf for dhcwg@optimus.ietf.org; Fri, 27 Jun 2003 16:17:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18609 for ; Fri, 27 Jun 2003 16:16:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VzU6-0005va-00 for dhcwg@ietf.org; Fri, 27 Jun 2003 16:06:14 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19VzTl-0005ug-00 for dhcwg@ietf.org; Fri, 27 Jun 2003 16:05:53 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5RK3q8w289438; Fri, 27 Jun 2003 16:03:52 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5RK3pPB113720; Fri, 27 Jun 2003 14:03:51 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h5RK348k004702; Fri, 27 Jun 2003 16:03:04 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h5RK34Rk004698; Fri, 27 Jun 2003 16:03:04 -0400 Message-Id: <200306272003.h5RK34Rk004698@rotala.raleigh.ibm.com> To: Ralph Droms cc: mjs@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] AD review of draft-ietf-dhc-relay-agent-auth-01.txt In-Reply-To: Message from rdroms@cisco.com of "Fri, 27 Jun 2003 14:38:12 EDT." <4.3.2.7.2.20030625173824.00bbd0f8@funnel.cisco.com> Date: Fri, 27 Jun 2003 16:03:04 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Ralph. > The two techniques in this document both address the same > problem: the authentication of messages exchanged between > DHCP relay agents and DHCP servers. Yes. But the solutions are very different, and will likely be implemented by different people or as different products. I.e,. the IPsec part will require help from the platform on which the server runs, as opposed to be part of the DHC package. In fact, it may be implementable without touching the DHC server at all. Another thing, when vendors say "we've implemented RFC XX", will that mean the IPsec technique, or the relay agent option, or both? Having both in the same document will likely be a bit more confusing. > The title of the document should, perhaps, read "Authentication of > DHCP Message Exchanged Between Relay Agents and Servers". The two > techniques for authentication are described in a single document > because they are applicable in different scenarios. If both were likely to be implemented together, I'd not have an issue with this. But I suspect this won't be the case. > Prior to the last dhc WG meeting, you had asked for a comparison > of the two techniques, which John Schnizlein published on the > dhc WG mailing list. Based on that comparison, the consensus > of the WG was that the two techniques should be advanced > together, because neither was appropriate for all operational > scenarios. I have no problem with this. > At the dhc WG meeting in San Francisco we agreed > to advance the two techniques in a single document. I guess I wasn't paying attention during this part of the conversation, and am suggesting that keeping them in separate documents would be preferable. > The description of the use of IPsec for authentication was copied > from an earlier draft of the DHCPv6 specification. The text in > draft-ietf-dhc-relay-agent-auth-01.txt is the same as in the version > of the DHCPv6 specification that has been accepted as a Proposed > Standard. The more detailed list of rules in the DHCPv6 > specification will be used as the basis to provide additional detail > in this document. Fair enough. For background, I was also partly reflecting a private comment bellovin made a while back when I pointed him to the document. He said it was "thin" (or some such) and would probably need more detail. But he didn't provide specifics. It's also the case that in the IESG, we've seen a number of documents that for security say "just use IPsec". But in practice, the details can sometimes be tricky if you really want interoperability. E.g., there is a whole document on the topic for L2tp (RFC 3193). And MIPv6 also has a separate document (draft-ietf-mobileip-mipv6-ha-ipsec-03.html). In any case, I think we probably agree that there are fairly few words. If folk from the IPsec community think that is all that is needed, great. But we haven't seen such a review yet, AFAIK. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 27 18:30:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23488; Fri, 27 Jun 2003 18:30:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jH-0007HV-Vp; Fri, 27 Jun 2003 18:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W06q-00010L-LW for dhcwg@optimus.ietf.org; Fri, 27 Jun 2003 16:46:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20046 for ; Fri, 27 Jun 2003 16:46:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W06o-0006HR-00 for dhcwg@ietf.org; Fri, 27 Jun 2003 16:46:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19W06d-0006HN-00 for dhcwg@ietf.org; Fri, 27 Jun 2003 16:46:04 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5RKjAgE011933; Fri, 27 Jun 2003 13:45:11 -0700 (PDT) Received: from rdroms-w2k.cisco.com ([161.44.65.118]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAG94863; Fri, 27 Jun 2003 16:45:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20030627163720.00ba6290@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Jun 2003 16:42:42 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] AD review of draft-ietf-dhc-unused-optioncodes-03.txt Cc: dhcwg@ietf.org In-Reply-To: <200306241559.h5OFxVK02817@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 11:59 AM 6/24/2003 -0400, Thomas Narten wrote: >The WG has asked that this document be advanced as an informational >RFC. > >Seems like an IETF Last Call on this document would be appropriate, >since the point is (in some sense) to verify that it is OK to reuse >the listed options for something else. Right? I agree that it would be useful to collect input from the entire IETF through an IETF last call. >My comments (all nits, I think). > > > Unused DHCP Option Codes > >A more descriptive title might be better? E.g.: > > Reclaiming Unused DHCP Option Codes for Reassignment for Future DHCP > Options. > >(or something similar) OK. > > > The following option codes are used in the "Preboot Execution > > Environment (PXE) Specification, Version 2.1" [4]. However, although > > these options are in widespread use by devices that use PXE, none of > > these option codes have been specified as a Standards-track RFC. > >remove mention of standards track (since this is not required?) I.e., >just getting them published as RFCs would be good. OK. > > 3.1 Client System > > > > Code: 93 > > > > Name: Client System > > > > Defined in: (none) > >Shouldn't you reference the PXE documents here? (ditto for remaining >PXE ones). > >Also, including the contact information in the option description >struck me a bit odd. As I was reading this, my first thought was "has >this person been contacted, and what did they say?" The document could >include an indication of this. OK. > > Normative References > >Hmm. Aren't all of the references actually informative? Which ones are >critical to *this* document? I think at least this ref is normative: [1] Assigned Numbers Editor, IANA., "BOOTP and DHCP Parameters", http://www.iana.org/assignments/bootp-dhcp-parameters, February 2003. And this ref gives the definition of the PXE options, and should be normative: [4] Intel Corporation, , "Preboot Execution Environment (PXE) Specification Version 2.1", http://www.pix.net/software/pxeboot/archive/pxespec.pdf, September 1999. This ref is arguably normative as it defines a potential use for two of the options under review: [5] Volz, B., Droms, R. and T. Lemon, "Extending DHCP Options Codes", draft-volz-dhc-extended-optioncodes-00.txt (work in progress), September 2000. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 27 19:44:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26425; Fri, 27 Jun 2003 19:44:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W2sq-0007sE-No; Fri, 27 Jun 2003 19:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W2rg-0007lx-Hv for dhcwg@optimus.ietf.org; Fri, 27 Jun 2003 19:43:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26372; Fri, 27 Jun 2003 19:42:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W2rP-0007Rt-00; Fri, 27 Jun 2003 19:42:31 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19W2rE-0007RT-00; Fri, 27 Jun 2003 19:42:20 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h5RNV1wQ009746; Fri, 27 Jun 2003 17:31:01 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C33D04.2B6D6920" Date: Fri, 27 Jun 2003 17:31:01 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Update to draft-ietf-dhc-suboptions-kdcserveraddress Thread-Index: AcM9BCt0ydpH4uk0QZKmhv7xTjR/TQ== From: "Kevin Luehrs" To: Cc: "John Bevilacqua @ YAS" , , "Nancy Davoust" , X-Approved: ondar Subject: [dhcwg] Update to draft-ietf-dhc-suboptions-kdcserveraddress Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C33D04.2B6D6920 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C33D04.2B6D6920" ------_=_NextPart_002_01C33D04.2B6D6920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This version of the 'draft-ietf-dhc-suboptions-kdcserveraddress' internet draft addresses comments received from the DHC WG on the -03 version. Please accept this latest version for further review by the DHC WG. This sub-option to the CableLabs Client Configuration option [RFC 3495] is needed to configure devices implementing CableLabs CableHome specifications in certain operating modes. <>=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kevin Luehrs Project Director, CableHome Engineering CableLabs 400 Centennial Parkway Louisville, CO 80027 303 661 9100 fax 303 661 9199 k.luehrs@cablelabs.com ------_=_NextPart_002_01C33D04.2B6D6920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Update to draft-ietf-dhc-suboptions-kdcserveraddress

This version of  the = 'draft-ietf-dhc-suboptions-kdcserveraddress' internet draft addresses = comments received from the DHC WG on the -03 version. Please accept this = latest version for further review by the DHC WG. This sub-option to the = CableLabs Client Configuration option [RFC 3495] is needed to configure = devices implementing CableLabs CableHome specifications in certain = operating modes.


= <<draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt>> =

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Luehrs
Project Director, CableHome = Engineering
CableLabs
400 Centennial Parkway
Louisville, CO 80027
303 661 9100
fax 303 661 9199
k.luehrs@cablelabs.com

------_=_NextPart_002_01C33D04.2B6D6920-- ------_=_NextPart_001_01C33D04.2B6D6920 Content-Type: text/plain; name="draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt Content-Disposition: attachment; filename="draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 CgoKSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBLLiBMdWVocnMKRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gV29ya2luZyBHcm91cCAgICAg ICAgICAgICAgICBDYWJsZUxhYnMKRXhwaXJlcyBEZWNlbWJlciAyMDAzICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBSLiBXb3VuZHkKCQkJCQkJCUNvbWNhc3QgQ2FibGUKCQkJCQkJ CUouIEJldmlsYWNxdWEgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgWUFTIENvcnBvcmF0aW9uICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTi4gRGF2b3VzdAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFlBUyBDb3Jwb3JhdGlv bgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEp1bmUgMjAwMwoKCgkJS0RDIFNlcnZlciBBZGRyZXNzIFN1Yi1vcHRpb24gCiAgICAgICAgIDxk cmFmdC1pZXRmLWRoYy1zdWJvcHRpb25zLWtkYy1zZXJ2ZXJhZGRyZXNzLTA0LnR4dD4KClN0YXR1 cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5k IGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aAogICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9u IDEwIG9mIFJGQzIwMjYuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0CiAgIG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQogICBEcmFm dHMuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCAKICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMKICAgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFw cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgCiAgIHJlZmVyZW5jZSBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0CgogICBUaGUgbGlzdCBv ZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgpDb3B5cmlnaHQgTm90aWNlCgogICBD b3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAzKS4gQWxsIFJpZ2h0cyBSZXNl cnZlZC4KCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgc3ViLW9wdGlv biBmb3IgdGhlIENhYmxlTGFicyBDbGllbnQKICAgQ29uZmlndXJhdGlvbiAoQ0NDKSBESENQIG9w dGlvbiBjb2RlIGZvciBjb252ZXlpbmcgdGhlIG5ldHdvcmsgCiAgIGFkZHJlc3NlcyBvZiBLZXkg RGlzdHJpYnV0aW9uIENlbnRlciAoS0RDKSBzZXJ2ZXJzLgoKMS4gIEludHJvZHVjdGlvbgoKICAg QSBDQ0MgREhDUCBPcHRpb24gY29kZSBwcm92aWRpbmcgdGhlIEtEQyBzZXJ2ZXIgYWRkcmVzcyB3 aWxsIGJlCiAgIG5lZWRlZCBmb3IgQ2FibGVIb21lLWNvbXBsaWFudCByZXNpZGVudGlhbCBnYXRl d2F5cyBjb25maWd1cmVkIHRvIAogICB1c2UgS2VyYmVyb3MgZm9yIGF1dGhlbnRpY2F0aW9uIGFz IHRoZSBmaXJzdCBzdGVwIGluIGVzdGFibGlzaGluZwogICBhIHNlY3VyZSBTTk1QdjMgbGluayBi ZXR3ZWVuIHRoZSBQUyBhbmQgdGhlIFNOTVAgZW50aXR5IGluIHRoZQogICBjYWJsZSBvcGVyYXRv cidzIGRhdGEgbmV0d29yay4KICAgCiAgIFRoZSBDQ0MgREhDUCBvcHRpb24gY29kZSB3aWxsIGJl IHVzZWQgdG8gYWRkcmVzcyBzcGVjaWZpYyBuZWVkcyBvZiAKICAgQ2FibGVMYWJzIGNsaWVudCBk ZXZpY2VzIGR1cmluZyB0aGVpciBjb25maWd1cmF0aW9uIHByb2Nlc3Nlcy4gVGhpcyAKICAgZG9j dW1lbnQgcHJvcG9zZXMgYSBzdWItb3B0aW9uIGZvciB0aGUgQ0NDIERIQ1Agb3B0aW9uLiAKICAg IAogICAKICAgTHVlaHJzLCBXb3VuZHksIEJldmlsYWNxdWEsJiBEYXZvdXN0ICBFeHBpcmVzIERl Y2VtYmVyIDIwMDMgW1BhZ2UgMV0MICAgSW50ZXJuZXQgRHJhZnQJIEtEQyBTZXJ2ZXIgQWRkcmVz cyBTdWItb3B0aW9uICAgICAgIEp1bmUgMjAwMwogICAKICAgCiAgIENvbmZpZ3VyYXRpb24gb2Yg YSBjbGFzcyBvZiBDYWJsZUxhYnMgY2xpZW50IGRldmljZXMgZGVzY3JpYmVkIGluIAogICBbMl0g YW5kIFszXSB3aWxsIHJlcXVpcmUgYSBESENQIHN1Yi1vcHRpb24gdG8gcHJvdmlkZSB0aGUgY2xp ZW50IAogICB3aXRoIHRoZSBuZXR3b3JrIGFkZHJlc3Mgb2YgYSBLREMgc2VydmVyIGluIHRoZSBj YWJsZSBvcGVyYXRvcidzIAogICBkYXRhIG5ldHdvcmsuIFRoZSBjbGFzcyBvZiBkZXZpY2VzIGFz c3VtZWQgaW4gWzJdIGFuZCBbM10gaXMgdW5saWtlIAogICB0aGUgY2xhc3Mgb2YgZGV2aWNlcyBj b25zaWRlcmVkIGluIFsxXSwgd2hpY2ggcGVyZm9ybSBhIEROUyBsb29rdXAKICAgb2YgdGhlIEtl cmJlcm9zIFJlYWxtIG5hbWUgdG8gZmluZCB0aGUgS0RDIHNlcnZlciBuZXR3b3JrIGFkZHJlc3Mu IAogICAKICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIHN1Yi1vcHRpb24gb2YgdGhlIENDQyBE SENQIG9wdGlvbgogICBjb2RlIGZvciB1c2Ugd2l0aCBDYWJsZUxhYnMgY2xpZW50IGRldmljZXMu IFRoZSBwcm9wb3NlZCBzdWItb3B0aW9uCiAgIGVuY29kZXMgYW4gaWRlbnRpZmllciBmb3IgdGhl IG5ldHdvcmsgYWRkcmVzcyBvZiBlYWNoIG9mIG9uZSBvciBtb3JlCiAgIEtleSBEaXN0cmlidXRp b24gQ2VudGVyIHNlcnZlcnMgd2l0aCB3aGljaCB0aGUgQ2FibGVMYWJzIGNsaWVudCAKICAgZGV2 aWNlIGV4Y2hhbmdlcyBzZWN1cml0eSBpbmZvcm1hdGlvbi4gCgogICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiBhbmQgIk1BWSIgCiAgIGlu IHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMg MjExOSBbNF0uCgoKMi4gIEtleSBEaXN0cmlidXRpb24gQ2VudGVyIElQIEFkZHJlc3MgU3ViLW9w dGlvbgoKICAgQ2FibGVIb21lIHNwZWNpZmljYXRpb25zIHdpbGwgc3BlY2lmeSB0aGUgS2V5IERp c3RyaWJ1dGlvbiAKICAgQ2VudGVyIG5ldHdvcmsgYWRkcmVzcyBlbmNvZGluZyBhcyBhIHN1Yi1v cHRpb24gb2YgdGhlIENDQyBESENQIAogICBPcHRpb24gY29kZS4gVGhpcyBmaWVsZCB3aWxsIGJl IHVzZWQgdG8gaW5mb3JtIHRoZSBjbGllbnQgZGV2aWNlIG9mIAogICB0aGUgbmV0d29yayBhZGRy ZXNzIG9mIG9uZSBvciBtb3JlIEtleSBEaXN0cmlidXRpb24gQ2VudGVyIHNlcnZlcnMuIAoKICAg VGhlIGVuY29kaW5nIG9mIHRoZSBLREMgU2VydmVyIEFkZHJlc3Mgc3ViLW9wdGlvbiB3aWxsIGFk aGVyZSB0byB0aGUgCiAgIGZvcm1hdCBvZiBhbiBJUHY0IGFkZHJlc3MuIFRoZSBtaW5pbXVtIGxl bmd0aCBmb3IgdGhpcyBvcHRpb24gaXMgNCAKICAgb2N0ZXRzLCBhbmQgdGhlIGxlbmd0aCBNVVNU IGFsd2F5cyBiZSBhIG11bHRpcGxlIG9mIDQuIElmIG11bHRpcGxlIAogICBLREMgU2VydmVycyBh cmUgbGlzdGVkLCB0aGV5IE1VU1QgYmUgbGlzdGVkIGluIGRlY3JlYXNpbmcgb3JkZXIgb2YgCiAg IHByaW9yaXR5LiBUaGUgZm9ybWF0IG9mIHRoZSBLREMgU2VydmVyIEFkZHJlc3Mgc3ViLW9wdGlv biBvZiB0aGUgQ0NDIAogICBvcHRpb24gY29kZSBpcyBhcyBzaG93biBiZWxvdzoKCiAgICBTdWJP cHQgIExlbiAgICAgIEFkZHJlc3MgMSAgICAgICAgICAgICAgIEFkZHJlc3MgMgogICArLS0tLS0t Ky0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tCiAgIHwgIFRCRCB8 ICBuICB8ICBhMSB8ICBhMiB8ICBhMyB8ICBhNCB8ICBhMSB8ICBhMiB8ICAuLi4KICAgKy0tLS0t LSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLQoKCjMuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCByZWxpZXMgdXBvbiB0aGUgREhD UCBwcm90b2NvbCBbNV0gZm9yIGF1dGhlbnRpY2F0aW9uCiAgIGFuZCBzZWN1cml0eSwgaS5lLiwg aXQgZG9lcyBub3QgcHJvdmlkZSBzZWN1cml0eSBpbiBleGNlc3Mgb2Ygd2hhdAogICBESENQIGlz IChvciB3aWxsIGJlKSBwcm92aWRpbmcuIFBvdGVudGlhbCBleHBvc3VyZXMgdG8gYXR0YWNrIGlu IAogICB0aGUgREhDUCBwcm90b2NvbCBhcmUgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNyBvZiB0aGUg REhDUCBwcm90b2NvbAogICBzcGVjaWZpY2F0aW9uIFs1XSBhbmQgaW4gQXV0aGVudGljYXRpb24g Zm9yIERIQ1AgTWVzc2FnZXMgWzZdLgoKICAgVGhlIENDQyBvcHRpb24gY2FuIGJlIHVzZWQgdG8g bWlzZGlyZWN0IG5ldHdvcmsgdHJhZmZpYyBieSBwcm92aWRpbmcKICAgaW5jb3JyZWN0IERIQ1Ag c2VydmVyIGFkZHJlc3NlcywgaW5jb3JyZWN0IHByb3Zpc2lvbmluZyBzZXJ2ZXIKICAgYWRkcmVz c2VzLCBhbmQgaW5jb3JyZWN0IEtlcmJlcm9zIHJlYWxtIG5hbWVzIHRvIGEgQ2FibGVMYWJzIGNs aWVudAogICBkZXZpY2UuICBUaGlzIG1pc2RpcmVjdGlvbiBjYW4gbGVhZCB0byBzZXZlcmFsIHRo cmVhdCBzY2VuYXJpb3MuICBBCiAgIERlbmlhbCBvZiBTZXJ2aWNlIChEb1MpIGF0dGFjayBjYW4g cmVzdWx0IGZyb20gYWRkcmVzcyBpbmZvcm1hdGlvbgogICBiZWluZyBzaW1wbHkgaW52YWxpZC4g IEEgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrIGNhbiBiZSBtb3VudGVkIGJ5CiAgIHByb3ZpZGlu ZyBhZGRyZXNzZXMgdG8gYSBwb3RlbnRpYWwgc25vb3Blci4gIEEgbWFsaWNpb3VzIHNlcnZpY2UK ICAgCiAgIAogICAKTHVlaHJzLCBXb3VuZHksIEJldmlsYWNxdWEsICYgRGF2b3VzdCAgRXhwaXJl cyBEZWNlbWJlciAyMDAzICAgW1BhZ2UgMl0KDEludGVybmV0IERyYWZ0CSBLREMgU2VydmVyIEFk ZHJlc3MgU3ViLW9wdGlvbiAgICAgICBKdW5lIDIwMDMKICAgCiAgIAogICBwcm92aWRlciBjYW4g c3RlYWwgY3VzdG9tZXJzIGZyb20gdGhlIGN1c3RvbWVyIHNlbGVjdGVkIHNlcnZpY2UgCiAgIHBy b3ZpZGVyLCBieSBhbHRlcmluZyB0aGUgS2VyYmVyb3MgcmVhbG0gZGVzaWduYXRpb24uCiAgIAog ICBUaGVzZSB0aHJlYXRzIGFyZSBtaXRpZ2F0ZWQgYnkgc2V2ZXJhbCBmYWN0b3JzLgoKICAgV2l0 aGluIHRoZSBjYWJsZSBkZWxpdmVyeSBhcmNoaXRlY3R1cmUgcmVxdWlyZWQgYnkgQ2FibGVMYWJz JyAKICAgUGFja2V0Q2FibGUsIERPQ1NJUywgYW5kIENhYmxlSG9tZSBzcGVjaWZpY2F0aW9ucywg dGhlIERIQ1AgY2xpZW50CiAgIGlzIGNvbm5lY3RlZCB0byBhIG5ldHdvcmsgdGhyb3VnaCBhIGNh YmxlIG1vZGVtIGFuZCB0aGUgQ01UUy4gIFRoZSAKICAgQ01UUyBpcyBleHBsaWNpdGx5IGNvbmZp Z3VyZWQgd2l0aCBhIHNldCBvZiBESENQIHNlcnZlcnMgdG8gd2hpY2ggCiAgIERIQ1AgcmVxdWVz dHMgYXJlIGZvcndhcmRlZC4gIEZ1cnRoZXIsIGEgY29ycmVjdGx5IGNvbmZpZ3VyZWQgQ01UUyAK ICAgd2lsbCBvbmx5IGFsbG93IGRvd25zdHJlYW0gdHJhZmZpYyBmcm9tIHNwZWNpZmljIElQIGFk ZHJlc3Nlcy8KICAgcmFuZ2VzLgoKICAgQXNzdW1pbmcgdGhhdCBzZXJ2ZXIgYWRkcmVzc2VzIHdl cmUgc3VjY2Vzc2Z1bGx5IHNwb29mZWQgdG8gdGhlIAogICBwb2ludCB0aGF0IGEgbWFsaWNpb3Vz IGNsaWVudCBkZXZpY2Ugd2FzIGFibGUgdG8gY29udGFjdCBhIEtEQywgdGhlCiAgIGNsaWVudCBk ZXZpY2UgbXVzdCBzdGlsbCBwcmVzZW50IHZhbGlkIGNlcnRpZmljYXRlcyB0byB0aGUgS0RDIAog ICBiZWZvcmUgYmVpbmcgc2VydmljZSBlbmFibGVkLiAgR2l2ZW4gdGhlIGNvbXB1dGF0aW9uYWwg b3ZlcmhlYWQgb2YgCiAgIHRoZSBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIHByb2Nlc3MsIHRoaXMg c2l0dWF0aW9uIGNvdWxkIHByZXNlbnQgYSAKICAgRG9TIG9wcG9ydHVuaXR5LgoKICAgSXQgaXMg cG9zc2libGUgZm9yIGEgbWFsaWNpb3VzIChhbHRob3VnaCBjZXJ0aWZpZWQpIHNlcnZpY2UKICAg cHJvdmlkZXIgdG8gcmVkaXJlY3QgYSBjdXN0b21lciBmcm9tIHRoZSBjdXN0b21lcidzIHNlbGVj dGVkIHNlcnZpY2UKICAgcHJvdmlkZXIuICBJdCBpcyBhc3N1bWVkIHRoYXQgYWxsIHNlcnZpY2Ug cHJvdmlkZXJzIHBlcm1pdHRlZCBvbnRvIAogICBhbiBhY2Nlc3MgcHJvdmlkZXJzIG5ldHdvcmsg YXJlIHRydXN0ZWQgZW50aXRpZXMgdGhhdCB3aWxsIGNvb3BlcmF0ZSAKICAgdG8gaW5zdXJlIHBl YWNlZnVsIGNvZXhpc3RlbmNlLiAgSWYgYSBzZXJ2aWNlIHByb3ZpZGVyIGlzIGZvdW5kIHRvIAog ICBiZSByZWRpcmVjdGluZyBjdXN0b21lcnMsIHRoaXMgc2hvdWxkIGJlIGhhbmRsZWQgYXMgYW4g CiAgIGFkbWluaXN0cmF0aXZlIG1hdHRlciBiZXR3ZWVuIHRoZSBhY2Nlc3MgcHJvdmlkZXIgYW5k IHRoZSBzZXJ2aWNlCiAgIHByb3ZpZGVyLgogICAKICAgQW5vdGhlciBzYWZlZ3VhcmQgdGhhdCBj YW4gYmUgdGFrZW4gYnkgc2VydmljZSBwcm92aWRlcnMgdG8gbGltaXQKICAgdGhlaXIgZXhwb3N1 cmUgdG8gdGhlaXIgS0RDIHNlcnZlcihzKSBpcyB0byBjb25maWd1cmUgdGhlaXIgbmV0d29yayAK ICAgc28gdGhhdCB0aGUgS0RDKHMpIHJlc2lkZSBvbiBhIHNlcGFyYXRlIHN1Ym5ldHdvcmsuCiAg IAogICBTZXJ2aWNlIHByb3ZpZGVycyBjYW4gZnVydGhlciBwcm90ZWN0IHRoZWlyIEtEQyBzZXJ2 ZXIocykgYnkgcGxhY2luZwogICBhIGZpcmV3YWxsIGluIGZyb250IG9mIHRoZSBLREMocylvbmx5 IGFsbG93aW5nIGNvbm5lY3Rpb25zIG5lZWRlZCAKICAgZm9yIGl0cyBjdXJyZW50IHByb3Zpc2lv bmluZyBwcm9jZXNzZXMuIFRoZSBJUCB0ZW1wb3JhcnkgYWRkcmVzc2VzIAogICBnaXZlbiB0aGUg Y2xpZW50IGRldmljZXMgZnJvbSB0aGUgREhDUCBzZXJ2ZXIgY291bGQgYmUgc2VudCBkaXJlY3Rs eQogICB0byB0aGUgZmlyZXdhbGwgZnJvbSB0aGUgREhDUCBzZXJ2ZXIgdG8gb3BlbiBhIGhvbGUg Zm9yIEtlcmJlcm9zIAogICBtZXNzYWdlcyBvbmx5IGZvciB0aG9zZSBwYXJ0aWN1bGFyIElQIGFk ZHJlc3NlcyBmb3IgYSBzaG9ydCBwZXJpb2QgCiAgIG9mIHRpbWUuIElmIHRoaXMgd2FzIHVzZWQg aXQgd291bGQgYmUgcmVjb21tZW5kZWQgdGhhdCBzZXJ2aWNlCiAgIHByb3ZpZGVycyBhdXRoZW50 aWNhdGUgdGhlaXIgREhDUCBzZXJ2ZXIgdG8gdGhlIEtEQyBhcyB3ZWxsLiBUaGlzIAogICBjb3Vs ZCBiZSBkb25lIHZpYSBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiByYXRoZXIgdGhhbiBkaWdpdGFs IAogICBjZXJ0aWZpY2F0ZSBkdWUgdG8gdGhlIGNvLWxvY2F0aW9uIG9mIHRoZSBESENQIHNlcnZl ciB0byB0aGUgS0RDLgogICAKICAgRmluYWxseSwgS2VyYmVyb3MgcmVxdWlyZXMgbXV0dWFsIGNs aWVudC1zZXJ2ZXIgYXV0aGVudGljYXRpb24uIAogICBUaGVyZWZvcmUsIHRoZSBjbGllbnQgZGV2 aWNlIG11c3QgYXV0aGVudGljYXRlIGl0c2VsZiB3aXRoIGl0cyAKICAgZGlnaXRhbCBjZXJ0aWZp Y2F0ZSBhbmQgdGhlIEtEQyBpcyByZXF1aXJlZCB0byBhdXRoZW50aWNhdGUgaXQgdG8gCiAgIHRo ZSBjbGllbnQgZGV2aWNlLiBJZiBhIGhhY2tlciB0cmllcyB0byByZWRpcmVjdCB0aGUgY2xpZW50 IGRldmljZSAKICAgYnkgcmVwbGFjaW5nIHRoZSBzZXJ2aWNlIHByb3ZpZGVyLWNvbmZpZ3VyZWQg S0RDIFNlcnZlciBBZGRyZXNzCiAgIHN1Yi1vcHRpb24gd2l0aCBhbm90aGVyIElQIGFkZHJlc3Ms IGl0IGlzIG5vdCBsaWtlbHkgdG8gYmUgYSB2YWxpZCAKICAgc2VydmljZSBwcm92aWRlcidzIEtE QyBzZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0aW9uIHdpbGwgZmFpbC4KICAgCiAgIAoKCgoKCkx1ZWhy cywgV291bmR5LCBCZXZpbGFjcXVhLCAmIERhdm91c3QgRXhwaXJlcyBEZWNlbWJlciAyMDAzICAg IFtQYWdlIDNdCgxJbnRlcm5ldCBEcmFmdAkgS0RDIFNlcnZlciBBZGRyZXNzIFN1Yi1vcHRpb24g ICAgICAgSnVuZSAyMDAzCgoKCjQuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGUgS0RDIFNl cnZlciBBZGRyZXNzIHN1Yi1vcHRpb24gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgCiAg IGludGVuZGVkIHRvIGJlIGEgc3ViLW9wdGlvbiBvZiB0aGUgQ2FibGVMYWJzIENsaWVudCBDb25m aWd1cmF0aW9uCiAgIChDQ0MpIG9wdGlvbiBkZXNjcmliZWQgaW4gWzFdLiBJQU5BIGlzIHJlcXVl c3RlZCB0byBhc3NpZ24gYW5kIAogICByZWdpc3RlciBhIHN1Yi1vcHRpb24gY29kZSBvZiB0aGUg Q0NDIG9wdGlvbiB0byB0aGUgS0RDIFNlcnZlciAKICAgQWRkcmVzcyBzdWItb3B0aW9uLgoKNS4g IE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgoKICAgWzFdICBCZXNlciwgQi4gYW5kIFAuIER1ZmZ5LCAi REhDUCBPcHRpb24gZm9yIENhYmxlTGFicyBDbGllbnQgCiAgICAgICAgQ29uZmlndXJhdGlvbiIs IFJGQyAzNDk1LCBNYXJjaCAyMDAzLgoKICAgWzJdICJDYWJsZUhvbWUgMS4xIFNwZWNpZmljYXRp b24gU1AtQ0gxLjEtSTAxLTAzMDQxOCIsIENhYmxlTGFicywKICAgICAgIEFwcmlsIDIwMDMsIGh0 dHA6Ly93d3cuY2FibGVsYWJzLmNvbS9wcm9qZWN0cy9jYWJsZWhvbWUvCiAgICAgICBzcGVjaWZp Y2F0aW9ucy8uCiAgIAogICBbM10gICJDYWJsZUhvbWUgMS4wIFNwZWNpZmljYXRpb24gU1AtQ0gx LjAtSTA0LTAzMDQxMSIsIENhYmxlTGFicywKICAgICAgCUFwcmlsIDIwMDMsIGh0dHA6Ly93d3cu Y2FibGVsYWJzLmNvbS9wcm9qZWN0cy9jYWJsZWhvbWUvCglzcGVjaWZpY2F0aW9ucy8uCgogICBb NF0gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJl cXVpcmVtZW50CiAgICAgICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoK ICAgWzVdIERyb21zLCBSLiwgIkR5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIiwg UkZDIDIxMzEsIE1hcmNoCiAgICAgICAxOTk3LgogICAgICAgCiAgIFs2XSBEcm9tcywgUi4gYW5k IFcuIEFyYmF1Z2gsICJBdXRoZW50aWNhdGlvbiBmb3IgREhDUCBNZXNzYWdlcyIsIFJGQwogICAg ICAgMzExOCwgSnVuZSAyMDAxCgo2LiAgQXV0aG9ycycgQWRkcmVzc2VzCgoJS2V2aW4gTHVlaHJz CglDYWJsZUxhYnMKCTQwMCBDZW50ZW5uaWFsIFBhcmt3YXkKCUxvdWlzdmlsbGUsIENPIDgwMDI3 CglQaG9uZTogICgzMDMpIDY2MS05MTAwCglFTWFpbDogIGsubHVlaHJzQGNhYmxlbGFicy5jb20K CglSaWNoYXJkIFdvdW5keQoJQ29tY2FzdCBDYWJsZQoJMjcgSW5kdXN0cmlhbCBEcml2ZQoJQ2hl bG1zZm9yZCwgTUEgMDE4MjQKCVBob25lOiAoOTc4KSAyNDQtNDAxMAoJRU1haWw6IHJpY2hhcmRf d291bmR5QGNhYmxlLmNvbWNhc3QuY29tCgogICAgICAgIEpvaG4gQmV2aWxhY3F1YQogICAgICAg IFlBUyBDb3Jwb3JhdGlvbgogICAgICAgIDMwMCBCcmlja3N0b25lIFNxdWFyZQogICAgICAgIEFu ZG92ZXIsIE1BIDAxODEwCiAgICAgICAgUGhvbmU6ICg5NzgpIDc0OS05OTk5CiAgICAgICAgRU1h aWw6IGpvaG5AeWFzLmNvbQoKCgoKTHVlaHJzLCBXb3VuZHksIEJldmlsYWNxdWEsICYgRGF2b3Vz dCAgRXhwaXJlcyBEZWNlbWJlciAyMDAzICAgW1BhZ2UgNF0KDEludGVybmV0IERyYWZ0CSBLREMg U2VydmVyIEFkZHJlc3MgU3ViLW9wdGlvbiAgICAgICBKdW5lIDIwMDMKCgoKICAgICAgICBOYW5j eSBEYXZvdXN0CiAgICAgICAgWUFTIENvcnBvcmF0aW9uCiAgICAgICAgMzAwIEJyaWNrc3RvbmUg U3F1YXJlCiAgICAgICAgQW5kb3ZlciwgTUEgMDE4MTAKICAgICAgICBQaG9uZTogKDk3OCkgNzQ5 LTk5OTkKCUVNYWlsOiBuYW5jeUB5YXMuY29tCgoKNy4gIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVu dAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuIEFsbCBSaWdo dHMgUmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5 IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvCiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29y a3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBleHBsYWluIGl0CiAgIG9yIGFzc2lzdCBp biBpdHMgaW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZAog ICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rp b24gb2YgYW55CiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3Rp Y2UgYW5kIHRoaXMgcGFyYWdyYXBoIAogICBhcmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVz IGFuZCBkZXJpdmF0aXZlIHdvcmtzLiAgSG93ZXZlciwgdGhpcwogICBkb2N1bWVudCBpdHNlbGYg bWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nCiAgIHRo ZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkg b3Igb3RoZXIKICAgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3Ig dGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcC0KICAgaW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGlj aCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRzCiAgIGRlZmluZWQgaW4gdGhlIElu dGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11c3QgYmUgZm9sbG93ZWQsIG9yIGFzCiAgIHJlcXVp cmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuIEVuZ2xpc2guCgog ICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5k IHdpbGwgbm90IGJlCiAgIHJldm9rZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1 Y2Nlc3NvcnMgb3IgYXNzaWducy4KCgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HCiAgIFRB U0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO Q0xVRElORwogICBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBP RiBUSEUgSU5GT1JNQVRJT04KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMg T1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiAKICAgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoKCkFja25vd2xlZGdlbWVudAoKICAgIEZ1bmRp bmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieQog ICAgdGhlIEludGVybmV0IFNvY2lldHkuCgoKCgoKCgoKCgoKCgoKCkx1ZWhycywgV291bmR5LCBC ZXZpbGFjcXVhLCYgRGF2b3VzdCAgIEV4cGlyZXMgRGVjZW1iZXIgMjAwMyAgIFtQYWdlIDVdCg== ------_=_NextPart_001_01C33D04.2B6D6920-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 28 10:20:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24055; Sat, 28 Jun 2003 10:20:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WGYb-0008ML-WD; Sat, 28 Jun 2003 10:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WGYW-0008Lg-Oq for dhcwg@optimus.ietf.org; Sat, 28 Jun 2003 10:19:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24032 for ; Sat, 28 Jun 2003 10:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WGYU-0003Mz-00 for dhcwg@ietf.org; Sat, 28 Jun 2003 10:19:54 -0400 Received: from [203.124.140.169] (helo=websmtp.corp.mphasis.com) by ietf-mx with smtp (Exim 4.12) id 19WGYJ-0003Mo-00 for dhcwg@ietf.org; Sat, 28 Jun 2003 10:19:43 -0400 Received: FROM bkorex02.corp.mphasis.com BY websmtp.corp.mphasis.com ; Sat Jun 28 19:50:04 2003 +0500 Received: from BKOREX01.corp.mphasis.com ([164.164.60.246]) by bkorex02.corp.mphasis.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 28 Jun 2003 19:50:04 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 28 Jun 2003 19:50:04 +0530 Message-ID: Thread-Topic: Problem in obtaining lease across VLANs Thread-Index: AcM9gF5GyUXRNVNBQqK/ByGsfLOFFA== From: "Shantharam K" To: X-OriginalArrivalTime: 28 Jun 2003 14:20:04.0742 (UTC) FILETIME=[5E857A60:01C33D80] Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Problem in obtaining lease across VLANs Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi All, I have multiple VLANs in my network and DHCP server is placed in one = VLAN. This DHCP serves all other VLAN clients with multiple scope. I = have put "HELPER ADDRESS" command in all VLAN routers to pass the DHCP = broadcast. This configuration is working fine. Now I am trying to control inter VLAN traffic through Access Lists. But = once I put access list on the VLAN routers DHCP requests are getting = blocked some where. Even though Access list allows all traffic to DHCP = server's VLAN, Clients are not able to obtain the IP leases from DHCP = server. Your help in resolving this issue would be greatly appreciated. Thanks and Regards -------- Shantharam K MphasiS-BFL Ltd., 139/1, Aditya Complex, Hosur Main Road, Koramangala, Bangalore-560 095 Phone : +91 80 5522713/714 Extn. 1012 Mobile: +91 98861 23015 Fax : +91 80 5522719 www.mphasis.com=20 Architecting Value SEI Level 5 ISO9001 Information transmitted by this e-mail is proprietary to MphasiS and/ or = its Customers and is intended for use only by the individual or entity = to which it is addressed, and may contain information that is = privileged, confidential or exempt from disclosure under applicable law. = If you are not the intended recipient or it appears that this mail has = been forwarded to you without proper authority, you are notified that = any use or dissemination of this information in any manner is strictly = prohibited. In such cases, please notify us immediately at = mailmaster@mphasis.com and delete this = mail from your records. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 30 17:37:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17325; Mon, 30 Jun 2003 17:37:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X6Kb-0002pV-AA; Mon, 30 Jun 2003 17:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X6KE-0002lQ-3b for dhcwg@optimus.ietf.org; Mon, 30 Jun 2003 17:36:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17292 for ; Mon, 30 Jun 2003 17:36:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X6KB-0004YY-00 for dhcwg@ietf.org; Mon, 30 Jun 2003 17:36:35 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19X6K1-0004YG-00 for dhcwg@ietf.org; Mon, 30 Jun 2003 17:36:25 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5ULZYg5003264 for ; Mon, 30 Jun 2003 17:35:34 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.65.118]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI03635; Mon, 30 Jun 2003 17:35:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20030630173133.048e58a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jun 2003 17:33:06 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] dhc WG meeting in Vienna Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here is a draft agenda for the dhc WG meeting in Vienna: Administrivia; agenda bashing Ralph Droms 05 minutes IPv4 Network Attachment Detection Bernard Aboba 15 minutes RFC3118 Delayed Authentication Using PANA Alper Yegin 15 minutes DHCP PXE Suboptions ??? 15 minutes DHCP-DDNS interaction Ralph Droms 30 minutes ----------- Total 80 minutes If you have additional topics you want to get on the agenda, please contact me as soon as possible. The current agenda for the IETF meeting in Vienna shows the dhc WG scheduled for Tue AM: TUESDAY, July 15, 2003 0900-1130 Morning Sessions APP geopriv Geographic Location/Privacy WG GEN problem Problem Statement WG INT dhc Dynamic Host Configuration WG OPS mboned MBONE Deployment WG SEC enroll Credential and Provisioning BOF SUB mpls Multiprotocol Label Switching WG TSV ippm IP Performance Metrics WG TSV rohc Robust Header Compression WG - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 30 17:52:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17693; Mon, 30 Jun 2003 17:52:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X6Z7-0003pu-8G; Mon, 30 Jun 2003 17:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X6Yt-0003pb-J6 for dhcwg@optimus.ietf.org; Mon, 30 Jun 2003 17:51:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17684 for ; Mon, 30 Jun 2003 17:51:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X6Yr-0004ek-00 for dhcwg@ietf.org; Mon, 30 Jun 2003 17:51:45 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19X6Yg-0004eF-00 for dhcwg@ietf.org; Mon, 30 Jun 2003 17:51:34 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5ULogIn010383 for ; Mon, 30 Jun 2003 14:50:43 -0700 (PDT) Received: from rdroms-w2k.cisco.com ([161.44.65.118]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI04425; Mon, 30 Jun 2003 17:50:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20030630173133.048e58a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jun 2003 17:42:16 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] dhc WG meeting in Vienna Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here is a draft agenda for the dhc WG meeting in Vienna: Administrivia; agenda bashing Ralph Droms 05 minutes IPv4 Network Attachment Detection Bernard Aboba 15 minutes RFC3118 Delayed Authentication Using PANA Alper Yegin 15 minutes DHCP PXE Suboptions ??? 15 minutes DHCP-DDNS interaction Ralph Droms 30 minutes ----------- Total 80 minutes If you have additional topics you want to get on the agenda, please contact me as soon as possible. The current agenda for the IETF meeting in Vienna shows the dhc WG scheduled for Tue AM: TUESDAY, July 15, 2003 0900-1130 Morning Sessions APP geopriv Geographic Location/Privacy WG GEN problem Problem Statement WG INT dhc Dynamic Host Configuration WG OPS mboned MBONE Deployment WG SEC enroll Credential and Provisioning BOF SUB mpls Multiprotocol Label Switching WG TSV ippm IP Performance Metrics WG TSV rohc Robust Header Compression WG - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 30 23:38:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28370; Mon, 30 Jun 2003 23:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XBxx-0006rO-7Q; Mon, 30 Jun 2003 23:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XBxC-0006jo-JS for dhcwg@optimus.ietf.org; Mon, 30 Jun 2003 23:37:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28346 for ; Mon, 30 Jun 2003 23:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XBx5-0006fV-00 for dhcwg@ietf.org; Mon, 30 Jun 2003 23:37:07 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19XBwq-0006em-00 for dhcwg@ietf.org; Mon, 30 Jun 2003 23:36:52 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h613Xc2K023688; Mon, 30 Jun 2003 20:33:39 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-98.cisco.com [10.82.240.98]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI16941; Mon, 30 Jun 2003 23:33:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20030630232536.047abd30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jun 2003 23:31:06 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] AD review of draft-ietf-dhc-unused-optioncodes-03.txt Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thomas, I've published draft-ietf-dhc-unused-optioncodes-04.txt, which includes the changes agreed to below. Please announce an IETF last call on the document. Michael Johnston has published "DHCP Preboot eXecution Environment Suboptions" , which documents the three PXE options. I've set aside a slot in the dhc WG meeting in Vienna for discussion of the details of this document and next steps for the PXE options. - Ralph ===== At 11:59 AM 6/24/2003 -0400, Thomas Narten wrote: >The WG has asked that this document be advanced as an informational >RFC. > >Seems like an IETF Last Call on this document would be appropriate, >since the point is (in some sense) to verify that it is OK to reuse >the listed options for something else. Right? I agree that it would be useful to collect input from the entire IETF through an IETF last call. >My comments (all nits, I think). > > > Unused DHCP Option Codes > >A more descriptive title might be better? E.g.: > > Reclaiming Unused DHCP Option Codes for Reassignment for Future DHCP > Options. > >(or something similar) OK. > > The following option codes are used in the "Preboot Execution > > Environment (PXE) Specification, Version 2.1" [4]. However, although > > these options are in widespread use by devices that use PXE, none of > > these option codes have been specified as a Standards-track RFC. > >remove mention of standards track (since this is not required?) I.e., >just getting them published as RFCs would be good. OK. > > 3.1 Client System > > > > Code: 93 > > > > Name: Client System > > > > Defined in: (none) > >Shouldn't you reference the PXE documents here? (ditto for remaining >PXE ones). > >Also, including the contact information in the option description >struck me a bit odd. As I was reading this, my first thought was "has >this person been contacted, and what did they say?" The document could >include an indication of this. OK. > > Normative References > >Hmm. Aren't all of the references actually informative? Which ones are >critical to *this* document? I think at least this ref is normative: [1] Assigned Numbers Editor, IANA., "BOOTP and DHCP Parameters", http://www.iana.org/assignments/bootp-dhcp-parameters, February 2003. And this ref gives the definition of the PXE options, and should be normative: [4] Intel Corporation, , "Preboot Execution Environment (PXE) Specification Version 2.1", http://www.pix.net/software/pxeboot/archive/pxespec.pdf, September 1999. This ref is arguably normative as it defines a potential use for two of the options under review: [5] Volz, B., Droms, R. and T. Lemon, "Extending DHCP Options Codes", draft-volz-dhc-extended-optioncodes-00.txt (work in progress), September 2000. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg