From dhcwg-admin@ietf.org Mon Dec 1 08:48:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10176; Mon, 1 Dec 2003 08:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoPB-0007Zc-M1; Mon, 01 Dec 2003 08:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoOU-0007IS-EL for dhcwg@optimus.ietf.org; Mon, 01 Dec 2003 08:47:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10081 for ; Mon, 1 Dec 2003 08:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQoOT-0001px-00 for dhcwg@ietf.org; Mon, 01 Dec 2003 08:47:17 -0500 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 1AQoOS-0001ni-00 for dhcwg@ietf.org; Mon, 01 Dec 2003 08:47:16 -0500 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 hB1DkhAt009130 for ; Mon, 1 Dec 2003 05:46:44 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.206]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI02255; Mon, 1 Dec 2003 08:46:42 -0500 (EST) Message-Id: <4.3.2.7.2.20031201084548.01e38210@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Dec 2003 08:46:40 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] ***DRAFT*** minutes from dhc WG meeting in Minneapolis 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: , Included below are ***draft*** minutes from the WG meeting in Minneapolis. Please review and respond with comments before 9AM EST, Fri 12/5. - Ralph ===== Administrivia Ralph Droms Agenda bashing Current last calls: failover; DHCPv4 threat analysis; PXE options New I-Ds to be considered by the dhc WG Droms reviewed 6 I-Ds that will be reviewed as WG work items; these I-Ds will be published after IETF 58 publication moratorium: DHCPv6 support for IPv6 Transition, A.K. Vijayabhaskar, S. Daniel Park DHCP Discovery Extensions, Rentschler DHCP Interface Information Option, Markus Rentschler DHCP Option for Proxy Server Configuration, Senthil K Balasubramanian The Extended Remote Boot Option for DHCPv4, A.K. Vijayabhaskar, B. Senthil Kumar DHCPv6 Support for Remote Boot, A.K. Vijayabhaskar, B. Senthil Kumar Node-Specific Client Identifiers for DHCPv4 Ted Lemon This draft defines a new DHCPv4 client identifier modeled on the DHCPv6 DUID (see section 9 of RFC 3315). The document requires a minor revision prior to WG last call. The isssues in section 4.3, "Changes to RFC 2131", will require that this standard be published with the notation that it "updates RFC 2131". The changes specified in this document will be folded into RFC 2131bis for Full Standard. Rapid Reply Option for DHCPv4 S. D. Park This draft defines a "rapid reply" extension to DHCPv4 that provides the same function as "rapid commit" option in DHCPv6 (see section 22.14) of RFC 3315. The draft was accepted as a WG work item. The option will be renamed "rapid commit" to match the analgous option in DHCPv6. The authors will publish the draft as a dhc WG draft immediately after ID publication moratorium. Vendor-Identifying Vendor Options for DHCPv4 Ralph Droms This draft defines two new options for DHCPv4 that are equivalent to the "Vendor Class" and "Vendor-specific Information" options in DHCPv6 (see section 22.16 and 22.17 of RFC 3315). Ted Lemon noted a conflict between this draft RFC 3396, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", because the new DHCPv4 options require independent processing of multiple copies of the options, while RFC 3396 requires that all instances of an option be concatenated before processing. The conflict will be discussed on WG mailing list. The draft will be ready for WG last call after the conflict is resolved and a revised draft published. The revised draft will be published by 12/15/2003. Client Identifier option in server replies Ralph Droms This document defines an update to RFC 2131 that requires a server to include the Client Identifier option in replies, if the client included the option in the message to the server. The document was accepted as a WG workk item. It will be reviewed immediately and any updates to RFC 2131 will be folded into RFC 2131bis for Full Standard. The authros will publish the document as a dhc WG draft immediately after ID publication moratorium. Extending DHCP Options Codes Ralph Droms The WG reviewed the four alternatives for the identification of additional option codes for DHCPv4 presented in this document, and decided to pursue the following two alternatives as independent drafts: (1) redesignate option codes 128-223 to be assigned to new options (2) recover disused option codes (the "Impress Server" option being the canonical example) for reassignment to new options The authors will republish this document as two separate drafts. Implementation Issues with RFC 2131 Ralph Droms The WG was in general consensus that this document is close to completion. Several specific details will be discussed on the WG mailing list. There was interest in scheduling one or more conference call or a workshop to complete work on the document. There will be additional discussion of what to do with the document; alternatives include: (1) Publish current draft as Informational to stimulate discussion of implementation issues (2) Conduct additional mailing list discussion, conference calls and/or workshops before publication (3) Fold results into RFC 2131bis before publication of RFC 2131bis as Standard. DHCPv4 Threat Analysis Mimi Zohar The authors will publish another revision of this document, which will then be ready for WG last call. The WG will continue to solicit proposals for RFC 3118-compliant protocols that address problems identified in this doc. Platform integrity measurements Mimi Zohar The dhc WG will consult with other appropriate WGs to determine the semantics of the option, and the dhc WG will approve the final syntax. Discussion of DHCP authentication (Happened as suffix to discussion of draft-ietf-dhc-v4-threat-analysis-00.txt.) Configuration of dual-stack hosts with DHCP Ralph Droms The WG developed an initial list of potential issues in dual-stack hosts using DHCP (DHCPv4 and/or DHCPv6). Tim Chown volunteered to write up these issues and gather more from discussion on the dhc WG mailing list. ID to be published by 12/15/2003. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 1 10:11:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13649; Mon, 1 Dec 2003 10:11:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQphW-0004Vg-2I; Mon, 01 Dec 2003 10:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQpgp-0004TX-Te for dhcwg@optimus.ietf.org; Mon, 01 Dec 2003 10:10:19 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13482 for ; Mon, 1 Dec 2003 10:10:04 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AQpeN-0005YM-2E; Mon, 01 Dec 2003 10:07:47 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 01 Dec 2003 10:07:47 -0500 Subject: [dhcwg] Last Call: 'Authentication of DHCP Relay Agent Options Using IPsec' 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 WG to consider the following document: - 'Authentication of DHCP Relay Agent Options Using IPsec ' 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-12-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-ipsec-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 1 10:44:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15426; Mon, 1 Dec 2003 10:44:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqDR-0006cU-Bx; Mon, 01 Dec 2003 10:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqCW-0006bS-Cb for dhcwg@optimus.ietf.org; Mon, 01 Dec 2003 10:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15354 for ; Mon, 1 Dec 2003 10:42:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqCT-0003Uj-00 for dhcwg@ietf.org; Mon, 01 Dec 2003 10:43:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AQqCT-0003UX-00 for dhcwg@ietf.org; Mon, 01 Dec 2003 10:43:01 -0500 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 hB1FgQxg013604; Mon, 1 Dec 2003 10:42:26 -0500 (EST) Received: from kkinnear-w2k03.cisco.com ([161.44.65.124]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI11497; Mon, 1 Dec 2003 10:42:26 -0500 (EST) Message-Id: <4.3.2.7.2.20031201103825.025fda20@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Dec 2003 10:42:25 -0500 To: "Kostur, Andre" , "'dhcwg@ietf.org'" From: Kim Kinnear Subject: Re: [dhcwg] draft-ietf-dhc-leasequery-06 clarification Cc: kkinnear@cisco.com In-Reply-To: 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: , At 12:42 PM 11/27/2003, Kostur, Andre wrote: >I think that the draft has a potential ambiguity in handling option 82 in the leasequery replies. > >RFC 3046 mandates that option 82 SHOULD be the last option in the reply packet. The leasequery draft only says that it will be included in the packet if the relay requested option 82 (and assuming that the DHCP server has information to put in option 82). > >So, from a leasequery perspective, if the server has data to put in option 82, where should the draft specify that the option should be placed within the packet? Should it also specify that option 82 SHOULD be the last option within the packet, and may not be placed in the overloaded fields? Or should the draft specify that option 82 within the leasequery reply may be anywhere within the options field? > >My opinion on the matter: I think that the presence of option 82 within a leasequery reply serves a different purpose that the presence of option 82 within a "normal" DHCP reply. Within a normal reply, option 82 needs to be able to be removed by the Relay without potentially disrupting any 3118 authentication that may be in use. Also option 82 may be carrying some sort of "routing" information for where this reply is really destined for (which circuit ID, which remote ID, etc). However in a leasequery reply the presence of option 82 is simply "dead data" that is being passed from the DHCP server to the relay. It has no more significance within the packet than the presence of, say, option 3. Given these points, I would suggest that the draft specify that the option 82 inserted in a leasequery reply does not have to follow the rules of 3046, but is to be handled like any other option (order & positioning is irrelevant, it may be placed in overloads, etc...). I agree with your analysis. I would expect that we could add a sentence or two to clarify this situation as part of the IETF last call comment handling. >And come to think of it, another wrinkle within this mechanism: what would be the correct behaviour for a DHCP server which receives a leasequery that has an option 82? According to 3046, the DHCP server would be required to echo it back to the client, but that would overwrite (or append to) the existing option 82 (which is the one that was being sent back as part of the leasequery reply). Should the draft specify that a relay MUST NOT supply an option 82 in its leasequery? I would say that the leasequery client SHOULD NOT supply an option-82 in the leasequery request, and that the server MUST NOT echo it in the leasequery reply if one came in. Another sentence which I believe we can add when the time comes. Thanks for thinking through some of these edge conditions. Cheers -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 1 15:29:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27149; Mon, 1 Dec 2003 15:29:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQufF-0006s7-0U; Mon, 01 Dec 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQueT-0006r2-32 for dhcwg@optimus.ietf.org; Mon, 01 Dec 2003 15:28:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26912; Mon, 1 Dec 2003 15:27:58 -0500 (EST) Message-Id: <200312012027.PAA26912@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: Mon, 01 Dec 2003 15:27:58 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-nisconfig-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 : NIS Configuration Options for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-nisconfig-04.txt Pages : 6 Date : 2003-12-1 This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers [3], NIS+ Servers [3], NIS Client Domain Name [3], NIS+ Client Domain name [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-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-nisconfig-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-nisconfig-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-12-1151837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-nisconfig-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1151837.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 Dec 2 15:35:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08648; Tue, 2 Dec 2003 15:35:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHEc-0006e1-SF; Tue, 02 Dec 2003 15:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHDp-0006Wc-Gi for dhcwg@optimus.ietf.org; Tue, 02 Dec 2003 15:34:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08285; Tue, 2 Dec 2003 15:33:59 -0500 (EST) Message-Id: <200312022033.PAA08285@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, 02 Dec 2003 15:33:59 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-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 : Rapid Commit Option for DHCPv4 Author(s) : S. Park Filename : draft-ietf-dhc-rapid-commit-opt-00.txt Pages : 11 Date : 2003-12-2 This document defines a new DHCPv4 option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4- message exchange, expediting client configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-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-rapid-commit-opt-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-rapid-commit-opt-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-12-2153950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-rapid-commit-opt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-rapid-commit-opt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-2153950.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 Dec 2 15:35:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08647; Tue, 2 Dec 2003 15:35:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHEc-0006do-3V; Tue, 02 Dec 2003 15:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHDl-0006WV-Fm for dhcwg@optimus.ietf.org; Tue, 02 Dec 2003 15:34:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08264; Tue, 2 Dec 2003 15:33:55 -0500 (EST) Message-Id: <200312022033.PAA08264@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, 02 Dec 2003 15:33:54 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-09.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) Server MIB Author(s) : R. Hibbs, G. Waters Filename : draft-ietf-dhc-server-mib-09.txt Pages : 47 Date : 2003-12-2 This memo 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-09.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-server-mib-09.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-server-mib-09.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-12-2153941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-server-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-2153941.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Dec 3 03:24:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05670; Wed, 3 Dec 2003 03:24:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSIj-0008Ct-Tl; Wed, 03 Dec 2003 03:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSID-0008BD-TN for dhcwg@optimus.ietf.org; Wed, 03 Dec 2003 03:23:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05660 for ; Wed, 3 Dec 2003 03:23:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSIB-0004FN-00 for dhcwg@ietf.org; Wed, 03 Dec 2003 03:23:27 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1ARSIA-0004FE-00 for dhcwg@ietf.org; Wed, 03 Dec 2003 03:23:26 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119073>; Wed, 3 Dec 2003 09:12:22 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Wed, 3 Dec 2003 09:22:08 +0100 Message-ID: From: "Rentschler, Markus" To: dhcwg@ietf.org Subject: WG: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-09.txt Date: Wed, 3 Dec 2003 09:22:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain 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: , dhcpv4ServerAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF Dhcpv4ServerAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An optional list of addresses that are known by this server. The list MUST contain addresses that have not expired. The list MUST NOT contain addresses that have never been assigned by the server UNLESS the lease is pre-configured in the server (e.g., a static lease for a host). Expired leases MAY appear during the time they are 'remembered' by the server for subsequent assignment to the same host." ::= { dhcpv4ServerConfiguration 4 } > > Dhcpv4ServerAddressEntry ::= SEQUENCE { > dhcpv4ServerAddress > InetAddressIPv4, > dhcpv4ServerAddressSubnetMask > InetAddressPrefixLength, > dhcpv4ServerAddressRange > InetAddressIPv4, > dhcpv4ServerAddressLeaseType INTEGER, > dhcpv4ServerAddressTimeRemaining Unsigned32, > dhcpv4ServerAddressAllowedProtocol INTEGER, > dhcpv4ServerAddressServedProtocol INTEGER, > dhcpv4ServerAddressPhysicalAddress DhcpPhysicalAddress, > > dhcpv4ServerAddressClientId > OCTET STRING, > dhcpv4ServerAddressHostName > SnmpAdminString, > dhcpv4ServerAddressDomainName SnmpAdminString > } > > This is a table with entries that contains both trigger criteria and > parameters that are assigned after the trigger criteria have matched. Is > this table intended to be used to configure static leases ? To me the text > does not make this clear. > > Best Regards, > Markus > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Dec 3 15:28:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03833; Wed, 3 Dec 2003 15:28:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdbO-0001ll-B9; Wed, 03 Dec 2003 15:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdag-0001kP-K5 for dhcwg@optimus.ietf.org; Wed, 03 Dec 2003 15:27:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03512; Wed, 3 Dec 2003 15:27:02 -0500 (EST) Message-Id: <200312032027.PAA03512@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: Wed, 03 Dec 2003 15:27:02 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-nisconfig-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 : NIS Configuration Options for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Pages : 6 Date : 2003-12-3 This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers [3], NIS+ Servers [3], NIS Client Domain Name [3], NIS+ Client Domain name [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-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-dhcpv6-opt-nisconfig-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-dhcpv6-opt-nisconfig-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-12-3152519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-3152519.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Dec 3 16:14:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03832; Wed, 3 Dec 2003 15:28:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdbN-0001l3-Kc; Wed, 03 Dec 2003 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdaa-0001kB-Bl for dhcwg@optimus.ietf.org; Wed, 03 Dec 2003 15:27:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03495; Wed, 3 Dec 2003 15:26:56 -0500 (EST) Message-Id: <200312032026.PAA03495@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: Wed, 03 Dec 2003 15:26:56 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-stateless-02.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 : A Guide to Implementing Stateless DHCPv6 Service Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-stateless-02.txt Pages : 10 Date : 2003-12-3 Stateless DHCPv6 service is used by nodes to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-02.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-stateless-02.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-stateless-02.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-12-3152506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-stateless-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-stateless-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-3152506.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Dec 3 18:01:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13771; Wed, 3 Dec 2003 18:01:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARfzS-0000DN-UZ; Wed, 03 Dec 2003 18:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARfyl-0000BZ-H3 for dhcwg@optimus.ietf.org; Wed, 03 Dec 2003 18:00:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13725 for ; Wed, 3 Dec 2003 18:00:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARfyi-0003jD-00 for dhcwg@ietf.org; Wed, 03 Dec 2003 18:00:16 -0500 Received: from smtp002.mail.ukl.yahoo.com ([217.12.11.33]) by ietf-mx with smtp (Exim 4.12) id 1ARfyh-0003iv-00 for dhcwg@ietf.org; Wed, 03 Dec 2003 18:00:15 -0500 Received: from adsl-64-169-90-78.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.90.78 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 3 Dec 2003 22:59:43 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-09.txt Date: Wed, 3 Dec 2003 15:00:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal 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 The "dhcpv4ServerAddressTable" is NOT intended to be used for configuration of a DHCPv4 server, nor are ANY other tables declared in the proposed MIB extension. If the text does not make this clear I will consider suggested wording changes that will add the needed clarity. --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Rentschler, Markus > Sent: Wednesday, December 03, 2003 00:22 > > This is a table with entries that contains both trigger criteria and > parameters that are assigned after the trigger criteria have matched. Is > this table intended to be used to configure static leases? To > me the text does not make this clear. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Dec 3 18:14:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15108; Wed, 3 Dec 2003 18:14:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARgC1-0000t2-KS; Wed, 03 Dec 2003 18:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARgBU-0000sk-D3 for dhcwg@optimus.ietf.org; Wed, 03 Dec 2003 18:13:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14981 for ; Wed, 3 Dec 2003 18:13:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARgBQ-0003uc-00 for dhcwg@ietf.org; Wed, 03 Dec 2003 18:13:24 -0500 Received: from smtp004.mail.ukl.yahoo.com ([217.12.11.35]) by ietf-mx with smtp (Exim 4.12) id 1ARgBP-0003u5-00 for dhcwg@ietf.org; Wed, 03 Dec 2003 18:13:24 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.90.78 with login) by smtp004.mail.ukl.yahoo.com with SMTP; 3 Dec 2003 23:12:47 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Wed, 3 Dec 2003 15:13:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [dhcwg] new draft about documentation requirements for DHCPv4 changes 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 I've just posted a new draft suggesting several straightforward and common sense documentation requirements for any Internet-Draft or Request for Proposal that that suggests protocol, format, or data changes to DHCPv4. The draft could be extended to cover DHCPv6 as well, but the need was suggested to me during the review of RFC 2131 by Rob Stevens and myself: the clarity of the current text [in RFC 2131] might have been improved by requiring updates to message format tables, state transition diagrams, and other portions of earlier documents. Authors of current drafts in the pipeline who agree with my suggested documentation requirements should make any changes necessary to their drafts in advance of working group consideration of this new draft, which I'm proposing as a BCP. Thanks in advance, --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Dec 3 19:11:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17265; Wed, 3 Dec 2003 19:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARh5B-000339-Pg; Wed, 03 Dec 2003 19:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARh4O-00032e-8r for dhcwg@optimus.ietf.org; Wed, 03 Dec 2003 19:10:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17209 for ; Wed, 3 Dec 2003 19:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARh4K-0004kz-00 for dhcwg@ietf.org; Wed, 03 Dec 2003 19:10:08 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1ARh4J-0004kE-00 for dhcwg@ietf.org; Wed, 03 Dec 2003 19:10:08 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HPC00L55GFTZK@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 04 Dec 2003 09:09:29 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPC00467GF6TC@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 04 Dec 2003 09:09:06 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HPC0053XGF5HM@mmp2.samsung.com> for dhcwg@ietf.org; Thu, 04 Dec 2003 09:09:06 +0900 (KST) Date: Thu, 04 Dec 2003 09:09:38 +0900 From: Soohong Daniel Park To: dhcwg@ietf.org Cc: "'Vijayabhaskar A K'" , "'Soohong Daniel Park'" Message-id: <00e701c3b9fa$e86c9aa0$b7cbdba8@daniel> 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/mixed; boundary="Boundary_(ID_QqQUcXTlbrPi9Y5MGUedtw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [dhcwg] [I-D ACTION:draft-vijay-dhc-dhcpv6-ipv6trans-00.txt] so how about this draft ? 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_QqQUcXTlbrPi9Y5MGUedtw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Vijay and I both hoped that it would be discussed in minneapolis, but we missed the cut-off date. This draft is targeted to the DHCPv6 client to obtain available tunnel end point efficiently. Should this I-D have "-dhc-" in its name ? Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, December 04, 2003 5:27 AM > To: IETF-Announce: > Subject: I-D ACTION:draft-vijay-dhc-dhcpv6-ipv6trans-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : DHCPv6 support for IPv6 Transition > Author(s) : a. Vijayabhaskar > Filename : draft-vijay-dhc-dhcpv6-ipv6trans-00.txt > Pages : 5 > Date : 2003-12-3 > > For the newly deployed IPv6 networks to interoperate with > vastly deployed IPv4 networks, various transition mechanisms > had been proposed. One such mechanism is configured tunnels. > This document provides a mechanism by which the DHCPv6 > servers can provide information about the various configured > tunnel end points to reach the IPv6 nodes which are separated > by IPv4 networks. > > A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-ipv6trans-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-vijay-dhc-dhcpv6-ipv6trans-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-vijay-dhc-dhcpv6-ipv6trans-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. --Boundary_(ID_QqQUcXTlbrPi9Y5MGUedtw) Content-type: Message/External-body; name=ATT00103.dat Content-disposition: attachment; filename=ATT00103.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-3152615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vijay-dhc-dhcpv6-ipv6trans-00.txt --Boundary_(ID_QqQUcXTlbrPi9Y5MGUedtw) Content-type: Message/External-body; name=draft-vijay-dhc-dhcpv6-ipv6trans-00.txt Content-disposition: attachment; filename=draft-vijay-dhc-dhcpv6-ipv6trans-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-3152615.I-D@ietf.org> --Boundary_(ID_QqQUcXTlbrPi9Y5MGUedtw)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 4 02:30:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14205; Thu, 4 Dec 2003 02:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnw2-0004T9-J8; Thu, 04 Dec 2003 02:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnv3-0004Oa-Of for dhcwg@optimus.ietf.org; Thu, 04 Dec 2003 02:29:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14083 for ; Thu, 4 Dec 2003 02:28:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARnuz-0003Wu-00 for dhcwg@ietf.org; Thu, 04 Dec 2003 02:28:57 -0500 Received: from nt.hirschmann.ch ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1ARnuy-0003Wd-00 for dhcwg@ietf.org; Thu, 04 Dec 2003 02:28:56 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119088>; Thu, 4 Dec 2003 08:17:35 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Thu, 4 Dec 2003 08:27:27 +0100 Message-ID: From: "Rentschler, Markus" To: rbhibbs@pacbell.net, dhcwg@ietf.org Subject: AW: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-09.txt Date: Thu, 4 Dec 2003 08:27:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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 Barr, After reading the security considerations at the end of the document = and regarding the fact that the variables are declared as "read-only", it = became clear that the MIB is intended for information retrieval only. Suggestion: Wouldn't it be useful to extend the Dhcpv4ServerAddressTable with variable(s) that reflect the value of the received relay agent = information option ? Best Regards, Markus > -----Urspr=FCngliche Nachricht----- > Von: Barr Hibbs [SMTP:rbhibbs@pacbell.net] > Gesendet am: Donnerstag, 4. Dezember 2003 00:01 > An: dhcwg@ietf.org > Betreff: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-09.txt >=20 >=20 > The "dhcpv4ServerAddressTable" is NOT intended to be used for > configuration > of a DHCPv4 server, nor are ANY other tables declared in the proposed = MIB > extension. If the text does not make this clear I will consider = suggested > wording changes that will add the needed clarity. >=20 > --Barr >=20 >=20 > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf = Of > > Rentschler, Markus > > Sent: Wednesday, December 03, 2003 00:22 > > > > This is a table with entries that contains both trigger criteria = and > > parameters that are assigned after the trigger criteria have = matched. > Is > > this table intended to be used to configure static leases? To > > me the text does not make this clear. > > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 4 18:18:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24816; Thu, 4 Dec 2003 18:18:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2jR-00072y-2W; Thu, 04 Dec 2003 18:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2ic-000727-QD for dhcwg@optimus.ietf.org; Thu, 04 Dec 2003 18:17:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24743 for ; Thu, 4 Dec 2003 18:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2iN-0004Hn-00 for dhcwg@ietf.org; Thu, 04 Dec 2003 18:16:55 -0500 Received: from smtp001.mail.ukl.yahoo.com ([217.12.11.32]) by ietf-mx with smtp (Exim 4.12) id 1AS2iM-0004Fl-00 for dhcwg@ietf.org; Thu, 04 Dec 2003 18:16:55 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.90.78 with login) by smtp001.mail.ukl.yahoo.com with SMTP; 4 Dec 2003 23:16:20 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-09.txt Date: Thu, 4 Dec 2003 15:17:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal 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 With one very limited exception, the DHCPv4 Server MIB does NOT report ANY data supplied by the client. This strategy was intentionally chosen to keep the MIB small and simple (key requirements if we wished for it to be implemented) and also with the knowledge that a parallel effort was investigating an LDAP schema that could store ALL data values sent to or received from a client. The LDAP schema did not advance from I-D status, although there has been some recent discussion about it. --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Rentschler, Markus > Sent: Wednesday, December 03, 2003 23:27 > > Suggestion: > Wouldn't it be useful to extend the Dhcpv4ServerAddressTable with > variable(s) that reflect the value of the received relay agent information > option ? > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 4 18:29:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25183; Thu, 4 Dec 2003 18:29:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2u5-0007QO-FC; Thu, 04 Dec 2003 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2td-0007Pz-PL for dhcwg@optimus.ietf.org; Thu, 04 Dec 2003 18:28:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25128 for ; Thu, 4 Dec 2003 18:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2ta-0004PX-00 for dhcwg@ietf.org; Thu, 04 Dec 2003 18:28:30 -0500 Received: from smtp004.mail.ukl.yahoo.com ([217.12.11.35]) by ietf-mx with smtp (Exim 4.12) id 1AS2ta-0004P6-00 for dhcwg@ietf.org; Thu, 04 Dec 2003 18:28:30 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.90.78 with login) by smtp004.mail.ukl.yahoo.com with SMTP; 4 Dec 2003 23:27:59 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] What OID to use before it is officially assigned by IANA? Date: Thu, 4 Dec 2003 15:28:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200312041936.hB4JaTAE000522@guinness.omniscient.com> Importance: Normal 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 The "-08" draft went through Working Group Last Call and generated a small number of change requests which have been made and the "-09" draft posted on December 1. I expect that it will quickly pass muster and go to general Last Call before the end of the year, as we have dealt in advance with all issues raised by the MIB doctors. --Barr > -----Original Message----- > From: Todd Kover [mailto:kovert@omniscient.com] > Sent: Thursday, December 04, 2003 11:36 > > > I did not see this addressed in the dhcwg archives. My apologies if it > is. > > On Tue, 13 May 2003 14:36:51 -0700, you said: > > > if you choose an OID prior to IANA assignment, you will have to change > > it later, possibly under awkward circumstances. If you can wait, you > > should, as the Working Group Last Call period just ended this past > > Friday, so progress towards becoming an RFC should be relatively quick > > now. > > I'm facing the same sort of problem (or maybe I should just to write my > own MIB for private use with the bits that I care about). > > Is rebirth as an rfc still imminent? > > thanks, > -Todd _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 4 19:12:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27322; Thu, 4 Dec 2003 19:12:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3Zh-0000dj-46; Thu, 04 Dec 2003 19:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzH9-00054s-Lt for dhcwg@optimus.ietf.org; Thu, 04 Dec 2003 14:36:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10275 for ; Thu, 4 Dec 2003 14:36:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARzH6-00077d-00 for dhcwg@ietf.org; Thu, 04 Dec 2003 14:36:32 -0500 Received: from guinness.omniscient.com ([64.134.101.78]) by ietf-mx with esmtp (Exim 4.12) id 1ARzH6-00077Z-00 for dhcwg@ietf.org; Thu, 04 Dec 2003 14:36:32 -0500 Received: from guinness.omniscient.com (localhost [127.0.0.1]) by guinness.omniscient.com (8.12.10/8.12.10) with ESMTP id hB4JaTAE000522; Thu, 4 Dec 2003 14:36:29 -0500 (EST) Message-Id: <200312041936.hB4JaTAE000522@guinness.omniscient.com> To: "Barr Hibbs" cc: dhcwg@ietf.org Subject: Re: [dhcwg] What OID to use before it is officially assigned by IANA? References: <9CFB9DA5261CD611A29B00508B7890484A113B@ex-deu-munich02.force.de> Date: Thu, 04 Dec 2003 14:36:29 -0500 From: Todd Kover 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 did not see this addressed in the dhcwg archives. My apologies if it is. On Tue, 13 May 2003 14:36:51 -0700, you said: > if you choose an OID prior to IANA assignment, you will have to change > it later, possibly under awkward circumstances. If you can wait, you > should, as the Working Group Last Call period just ended this past > Friday, so progress towards becoming an RFC should be relatively quick > now. I'm facing the same sort of problem (or maybe I should just to write my own MIB for private use with the bits that I care about). Is rebirth as an rfc still imminent? thanks, -Todd _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 5 11:22:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11810; Fri, 5 Dec 2003 11:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIiP-0001Sj-4m; Fri, 05 Dec 2003 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIhg-0001Rx-6i for dhcwg@optimus.ietf.org; Fri, 05 Dec 2003 11:21:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11743; Fri, 5 Dec 2003 11:21:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASIhe-0003ka-00; Fri, 05 Dec 2003 11:21:14 -0500 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 1ASIhd-0003jh-00; Fri, 05 Dec 2003 11:21:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Dec 2003 08:21:34 +0000 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 hB5GKeAt002150; Fri, 5 Dec 2003 08:20:41 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-44.cisco.com [10.82.240.44]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEL40359; Fri, 5 Dec 2003 11:20:39 -0500 (EST) Message-Id: <4.3.2.7.2.20031205111515.00b590d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Dec 2003 11:20:36 -0500 To: minutes@ietf.org From: Ralph Droms Cc: narten@us.ibm.com, mrw@windriver.com, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_42686600==_" Subject: [dhcwg] Minutes from dhc WG meeting at IETF 58 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: , --=====================_42686600==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Attached are the minutes from the dhc WG meeting at IETF 58. - Ralph --=====================_42686600==_ Content-Type: text/plain; name="dhc-minutes.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="dhc-minutes.txt" Content-Transfer-Encoding: base64 CkFkbWluaXN0cml2aWEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJhbHBo IERyb21zIAogIEFnZW5kYSBiYXNoaW5nCiAgQ3VycmVudCBsYXN0IGNhbGxzOiBmYWlsb3Zlcjsg REhDUHY0IHRocmVhdCBhbmFseXNpczsgUFhFIG9wdGlvbnMKCk5ldyBJLURzIHRvIGJlIGNvbnNp ZGVyZWQgYnkgdGhlIGRoYyBXRwoKICBEcm9tcyByZXZpZXdlZCA2IEktRHMgdGhhdCB3aWxsIGJl IHJldmlld2VkIGFzIFdHIHdvcmsgaXRlbXM7IHRoZXNlCiAgSS1EcyB3aWxsIGJlIHB1Ymxpc2hl ZCBhZnRlciBJRVRGIDU4IHB1YmxpY2F0aW9uIG1vcmF0b3JpdW06CgogIERIQ1B2NiBzdXBwb3J0 IGZvciBJUHY2IFRyYW5zaXRpb24sCiAgPGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1pcHY2dHJhbnMt MDAudHh0PiAKICBBLksuIFZpamF5YWJoYXNrYXIsIFMuIERhbmllbCBQYXJrIAoKICBESENQIERp c2NvdmVyeSBFeHRlbnNpb25zLAogIDxkcmFmdC1yZW50c2NobGVyLWRoYy1kaXNjb3ZlcnktMDAu dHh0PgogIFJlbnRzY2hsZXIKIAogIERIQ1AgSW50ZXJmYWNlIEluZm9ybWF0aW9uIE9wdGlvbiwK ICA8ZHJhZnQtcmVudHNjaGxlci1kaGMtaW50ZXJmYWNlLW9wdC0wMC50eHQ+IAogIE1hcmt1cyBS ZW50c2NobGVyCgogIERIQ1AgT3B0aW9uIGZvciBQcm94eSBTZXJ2ZXIgQ29uZmlndXJhdGlvbiwK ICA8ZHJhZnQtaWV0Zi1kaGMtcHJveHlzZXJ2ZXItb3B0LTAwLnR4dD4gCiAgU2VudGhpbCBLIEJh bGFzdWJyYW1hbmlhbgoKICBUaGUgRXh0ZW5kZWQgUmVtb3RlIEJvb3QgT3B0aW9uIGZvciBESENQ djQsCiAgPGRyYWZ0LWlldGYtZGhjLW9wdC1leHRyYm9vdC0wMC50eHQ+IAogIEEuSy4gVmlqYXlh Ymhhc2thciwgQi4gU2VudGhpbCBLdW1hcgoKICBESENQdjYgU3VwcG9ydCBmb3IgUmVtb3RlIEJv b3QsCiAgPGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1vcHQtcmJvb3QtMDAudHh0PiAKICBBLksuIFZp amF5YWJoYXNrYXIsIEIuIFNlbnRoaWwgS3VtYXIKCgpOb2RlLVNwZWNpZmljIENsaWVudCBJZGVu dGlmaWVycyBmb3IgREhDUHY0ICAgICAgICBUZWQgTGVtb24KICA8ZHJhZnQtaWV0Zi1kaGMtMzMx NWlkLWZvci12NC0wMC50eHQ+CgogIFRoaXMgZHJhZnQgZGVmaW5lcyBhIG5ldyBESENQdjQgY2xp ZW50IGlkZW50aWZpZXIgbW9kZWxlZCBvbiB0aGUKICBESENQdjYgRFVJRCAoc2VlIHNlY3Rpb24g OSBvZiBSRkMgMzMxNSkuICBLaW0gS2lubmVhciBtYWRlIHRoZSBwb2ludAogIHRoYXQgaXQgd2Fz bid0IGNsZWFyIHRoYXQgb25seSBvbmUgbGVhc2UgcGVyIGNsaWVudCBwZXIgbGFuLXNlZ21lbnQK ICB3YXMgYWxsb3dlZCwgYW5kIFRlZCBzYWlkIHRoYXQgaGUnZCBmaXggdGhhdC4gIFRoZSBkb2N1 bWVudCByZXF1aXJlcwogIGEgbWlub3IgcmV2aXNpb24gcHJpb3IgdG8gV0cgbGFzdCBjYWxsLiAg VGhlIGlzc3N1ZXMgaW4gc2VjdGlvbiA0LjMsCiAgIkNoYW5nZXMgdG8gUkZDIDIxMzEiLCB3aWxs IHJlcXVpcmUgdGhhdCB0aGlzIHN0YW5kYXJkIGJlIHB1Ymxpc2hlZAogIHdpdGggdGhlIG5vdGF0 aW9uIHRoYXQgaXQgInVwZGF0ZXMgUkZDIDIxMzEiLiAgVGhlIGNoYW5nZXMgc3BlY2lmaWVkCiAg aW4gdGhpcyBkb2N1bWVudCB3aWxsIGJlIGZvbGRlZCBpbnRvIFJGQyAyMTMxYmlzIGZvciBGdWxs IFN0YW5kYXJkLgoKUmFwaWQgUmVwbHkgT3B0aW9uIGZvciBESENQdjQgICAgICAgICAgICAgICAg ICAgICAgUy4gRC4gUGFyawogIDxkcmFmdC12b2x6LWRoYy1yYXBpZHJlcGx5LW9wdC0wMC50eHQ+ CgogIFRoaXMgZHJhZnQgZGVmaW5lcyBhICJyYXBpZCByZXBseSIgZXh0ZW5zaW9uIHRvIERIQ1B2 NCB0aGF0IHByb3ZpZGVzCiAgdGhlIHNhbWUgZnVuY3Rpb24gYXMgInJhcGlkIGNvbW1pdCIgb3B0 aW9uIGluIERIQ1B2NiAoc2VlIHNlY3Rpb24KICAyMi4xNCkgb2YgUkZDIDMzMTUuIFRoZSBkcmFm dCB3YXMgYWNjZXB0ZWQgYXMgYSBXRyB3b3JrIGl0ZW0uICBUaGUKICBvcHRpb24gd2lsbCBiZSBy ZW5hbWVkICJyYXBpZCBjb21taXQiIHRvIG1hdGNoIHRoZSBhbmFsZ291cyBvcHRpb24KICBpbiBE SENQdjYuIFRoZSBhdXRob3JzIHdpbGwgcHVibGlzaCB0aGUgZHJhZnQgYXMgYSBkaGMgV0cgZHJh ZnQKICBpbW1lZGlhdGVseSBhZnRlciBJRCBwdWJsaWNhdGlvbiBtb3JhdG9yaXVtLgoKVmVuZG9y LUlkZW50aWZ5aW5nIFZlbmRvciBPcHRpb25zIGZvciBESENQdjQgICAgICAgUmFscGggRHJvbXMK CiAgVGhpcyBkcmFmdCBkZWZpbmVzIHR3byBuZXcgb3B0aW9ucyBmb3IgREhDUHY0IHRoYXQgYXJl IGVxdWl2YWxlbnQgdG8KICB0aGUgIlZlbmRvciBDbGFzcyIgYW5kICJWZW5kb3Itc3BlY2lmaWMg SW5mb3JtYXRpb24iIG9wdGlvbnMgaW4KICBESENQdjYgKHNlZSBzZWN0aW9uIDIyLjE2IGFuZCAy Mi4xNyBvZiBSRkMgMzMxNSkuICBUZWQgTGVtb24gbm90ZWQgYQogIGNvbmZsaWN0IGJldHdlZW4g dGhpcyBkcmFmdCBSRkMgMzM5NiwgIkVuY29kaW5nIExvbmcgT3B0aW9ucyBpbiB0aGUKICBEeW5h bWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCAoREhDUHY0KSIsIGJlY2F1c2UgdGhlIG5l dwogIERIQ1B2NCBvcHRpb25zIHJlcXVpcmUgaW5kZXBlbmRlbnQgcHJvY2Vzc2luZyBvZiBtdWx0 aXBsZSBjb3BpZXMgb2YKICB0aGUgb3B0aW9ucywgd2hpbGUgUkZDIDMzOTYgcmVxdWlyZXMgdGhh dCBhbGwgaW5zdGFuY2VzIG9mIGFuIG9wdGlvbgogIGJlIGNvbmNhdGVuYXRlZCBiZWZvcmUgcHJv Y2Vzc2luZy4gIFRoZSBjb25mbGljdCB3aWxsIGJlIGRpc2N1c3NlZAogIG9uIFdHIG1haWxpbmcg bGlzdC4gIFRoZSBkcmFmdCB3aWxsIGJlIHJlYWR5IGZvciBXRyBsYXN0IGNhbGwgYWZ0ZXIKICB0 aGUgY29uZmxpY3QgaXMgcmVzb2x2ZWQgYW5kIGEgcmV2aXNlZCBkcmFmdCBwdWJsaXNoZWQuICBU aGUgcmV2aXNlZAogIGRyYWZ0IHdpbGwgYmUgcHVibGlzaGVkIGJ5IDEyLzE1LzIwMDMuCgpDbGll bnQgSWRlbnRpZmllciBvcHRpb24gaW4gc2VydmVyIHJlcGxpZXMgICAgICAgICBSYWxwaCBEcm9t cwogIDxkcmFmdC1zd2FteS1kaGMtY2xpZW50LWlkLTAwLnR4dD4KICAKICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYW4gdXBkYXRlIHRvIFJGQyAyMTMxIHRoYXQgcmVxdWlyZXMgYSBzZXJ2ZXIKICB0 byBpbmNsdWRlIHRoZSBDbGllbnQgSWRlbnRpZmllciBvcHRpb24gaW4gcmVwbGllcywgaWYgdGhl IGNsaWVudAogIGluY2x1ZGVkIHRoZSBvcHRpb24gaW4gdGhlIG1lc3NhZ2UgdG8gdGhlIHNlcnZl ci4gIFRoZSBkb2N1bWVudCB3YXMKICBhY2NlcHRlZCBhcyBhIFdHIHdvcmtrIGl0ZW0uICBJdCB3 aWxsIGJlIHJldmlld2VkIGltbWVkaWF0ZWx5IGFuZAogIGFueSB1cGRhdGVzIHRvIFJGQyAyMTMx IHdpbGwgYmUgZm9sZGVkIGludG8gUkZDIDIxMzFiaXMgZm9yIEZ1bGwKICBTdGFuZGFyZC4gIFRo ZSBhdXRocm9zIHdpbGwgcHVibGlzaCB0aGUgZG9jdW1lbnQgYXMgYSBkaGMgV0cgZHJhZnQKICBp bW1lZGlhdGVseSBhZnRlciBJRCBwdWJsaWNhdGlvbiBtb3JhdG9yaXVtLgoKRXh0ZW5kaW5nIERI Q1AgT3B0aW9ucyBDb2RlcyAgICAgICAgICAgICAgICAgICAgICAgUmFscGggRHJvbXMKICA8ZHJh ZnQtaWV0Zi1kaGMtZXh0ZW5kZWQtb3B0aW9uY29kZXMtMDAudHh0PgoKICBUaGUgV0cgcmV2aWV3 ZWQgdGhlIGZvdXIgYWx0ZXJuYXRpdmVzIGZvciB0aGUgaWRlbnRpZmljYXRpb24gb2YKICBhZGRp dGlvbmFsIG9wdGlvbiBjb2RlcyBmb3IgREhDUHY0IHByZXNlbnRlZCBpbiB0aGlzIGRvY3VtZW50 LCBhbmQKICBkZWNpZGVkIHRvIHB1cnN1ZSB0aGUgZm9sbG93aW5nIHR3byBhbHRlcm5hdGl2ZXMg YXMgaW5kZXBlbmRlbnQKICBkcmFmdHM6CgogICgxKSByZWRlc2lnbmF0ZSBvcHRpb24gY29kZXMg MTI4LTIyMyB0byBiZSBhc3NpZ25lZCB0byBuZXcgb3B0aW9ucwogICgyKSByZWNvdmVyIGRpc3Vz ZWQgb3B0aW9uIGNvZGVzICh0aGUgIkltcHJlc3MgU2VydmVyIiBvcHRpb24gYmVpbmcKICAgICAg dGhlIGNhbm9uaWNhbCBleGFtcGxlKSBmb3IgcmVhc3NpZ25tZW50IHRvIG5ldyBvcHRpb25zCgog IFRoZSBhdXRob3JzIHdpbGwgcmVwdWJsaXNoIHRoaXMgZG9jdW1lbnQgYXMgdHdvIHNlcGFyYXRl IGRyYWZ0cy4KCkltcGxlbWVudGF0aW9uIElzc3VlcyB3aXRoIFJGQyAyMTMxICAgICAgICAgICAg ICAgIFJhbHBoIERyb21zCiAgPGRyYWZ0LWlldGYtZGhjLWltcGxlbWVudGF0aW9uLTAxLnR4dD4K CiAgVGhlIFdHIHdhcyBpbiBnZW5lcmFsIGNvbnNlbnN1cyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMg Y2xvc2UgdG8KICBjb21wbGV0aW9uLiAgU2V2ZXJhbCBzcGVjaWZpYyBkZXRhaWxzIHdpbGwgYmUg ZGlzY3Vzc2VkIG9uIHRoZSBXRwogIG1haWxpbmcgbGlzdC4gIFRoZXJlIHdpbGwgYmUgYSBXRyBj b25mZXJlbmNlIGNhbGwgYW5kLCBpZiBuZWNlc2FyeSwKICBhIHdvcmtzaG9wIHRvIGRpc2N1c3Mg YW55IG91dHN0YW5kaW5nIGlzc3Vlcy4gIFRoZXJlIHdpbGwgYmUKICBhZGRpdGlvbmFsIGRpc2N1 c3Npb24gb2Ygd2hhdCB0byBkbyB3aXRoIHRoZSBkb2N1bWVudDsgYWx0ZXJuYXRpdmVzCiAgaW5j bHVkZToKCiAgKDEpIFB1Ymxpc2ggY3VycmVudCBkcmFmdCBhcyBJbmZvcm1hdGlvbmFsIHRvIHN0 aW11bGF0ZSBkaXNjdXNzaW9uCiAgICAgIG9mIGltcGxlbWVudGF0aW9uIGlzc3VlcwogICgyKSBD b25kdWN0IGFkZGl0aW9uYWwgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24sIGNvbmZlcmVuY2UgY2Fs bHMKICAgICAgYW5kL29yIHdvcmtzaG9wcyBiZWZvcmUgcHVibGljYXRpb24KICAoMykgRm9sZCBy ZXN1bHRzIGludG8gUkZDIDIxMzFiaXMgYmVmb3JlIHB1YmxpY2F0aW9uIG9mIFJGQyAyMTMxYmlz CiAgICAgIGFzIFN0YW5kYXJkLgoKREhDUHY0IFRocmVhdCBBbmFseXNpcyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTWltaSBab2hhcgogIDxkcmFmdC1pZXRmLWRoYy12NC10aHJlYXQtYW5h bHlzaXMtMDAudHh0PgoKICBUaGUgYXV0aG9ycyB3aWxsIHB1Ymxpc2ggYW5vdGhlciByZXZpc2lv biBvZiB0aGlzIGRvY3VtZW50LCB3aGljaAogIHdpbGwgdGhlbiBiZSByZWFkeSBmb3IgV0cgbGFz dCBjYWxsLiAgVGhlIFdHIHdpbGwgY29udGludWUgdG8KICBzb2xpY2l0IHByb3Bvc2FscyBmb3Ig UkZDIDMxMTgtY29tcGxpYW50IHByb3RvY29scyB0aGF0IGFkZHJlc3MKICBwcm9ibGVtcyBpZGVu dGlmaWVkIGluIHRoaXMgZG9jLgoKUGxhdGZvcm0gaW50ZWdyaXR5IG1lYXN1cmVtZW50cyAgICAg ICAgICAgICAgICAgICAgTWltaSBab2hhcgoKICBUaGUgZGhjIFdHIHdpbGwgY29uc3VsdCB3aXRo IG90aGVyIGFwcHJvcHJpYXRlIFdHcyB0byBkZXRlcm1pbmUgdGhlCiAgc2VtYW50aWNzIG9mIHRo ZSBvcHRpb24sIGFuZCB0aGUgZGhjIFdHIHdpbGwgYXBwcm92ZSB0aGUgZmluYWwKICBzeW50YXgu CgpEaXNjdXNzaW9uIG9mIERIQ1AgYXV0aGVudGljYXRpb24KCiAgKEhhcHBlbmVkIGFzIHN1ZmZp eCB0byBkaXNjdXNzaW9uIG9mCiAgZHJhZnQtaWV0Zi1kaGMtdjQtdGhyZWF0LWFuYWx5c2lzLTAw LnR4dC4pCgpDb25maWd1cmF0aW9uIG9mIGR1YWwtc3RhY2sgaG9zdHMgd2l0aCBESENQICAgICAg ICBSYWxwaCBEcm9tcwoKICBUaGUgV0cgZGV2ZWxvcGVkIGFuIGluaXRpYWwgbGlzdCBvZiBwb3Rl bnRpYWwgaXNzdWVzIGluIGR1YWwtc3RhY2sKICBob3N0cyB1c2luZyBESENQIChESENQdjQgYW5k L29yIERIQ1B2NikuICBUaW0gQ2hvd24gdm9sdW50ZWVyZWQgdG8KICB3cml0ZSB1cCB0aGVzZSBp c3N1ZXMgYW5kIGdhdGhlciBtb3JlIGZyb20gZGlzY3Vzc2lvbiBvbiB0aGUgZGhjIFdHCiAgbWFp bGluZyBsaXN0LiAgSUQgdG8gYmUgcHVibGlzaGVkIGJ5IDEyLzE1LzIwMDMuCgo= --=====================_42686600==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Dec 7 11:47:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27396; Sun, 7 Dec 2003 11:47:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT23i-0001Z7-AO; Sun, 07 Dec 2003 11:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT22v-0001Xc-Nr for dhcwg@optimus.ietf.org; Sun, 07 Dec 2003 11:46:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27373 for ; Sun, 7 Dec 2003 11:45:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT22u-0002jq-00 for dhcwg@ietf.org; Sun, 07 Dec 2003 11:46:12 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AT22u-0002jn-00 for dhcwg@ietf.org; Sun, 07 Dec 2003 11:46:12 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hB7Gk1Ar032177; Sun, 7 Dec 2003 11:46:11 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Soohong Daniel Park'" , Cc: "'Vijayabhaskar A K'" Subject: RE: [dhcwg] [I-D ACTION:draft-vijay-dhc-dhcpv6-ipv6trans-00.txt] so how about this draft ? Date: Sun, 7 Dec 2003 11:46:02 -0500 Message-ID: <000001c3bce1$9df3a600$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <00e701c3b9fa$e86c9aa0$b7cbdba8@daniel> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable 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: I think you're asking whether to adopt this as a DHC WG work-item (i.e, = the I-D can have "-ietf-" in its name rather than "-vijay-")? I don't have = any issue in having the WG take on this draft, though I would recommend = renaming it to be more explicit that it's just defining an option for the = Configured Tunnel End-Point(s)? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Soohong Daniel Park Sent: Wednesday, December 03, 2003 7:10 PM To: dhcwg@ietf.org Cc: 'Vijayabhaskar A K'; 'Soohong Daniel Park' Subject: [dhcwg] [I-D ACTION:draft-vijay-dhc-dhcpv6-ipv6trans-00.txt] so = how about this draft ? Vijay and I both hoped that it would be discussed in minneapolis, but we missed the cut-off date. This draft is targeted to the DHCPv6 client to obtain available tunnel end point efficiently. Should this I-D have "-dhc-" in its name ? Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics=20 > -----Original Message----- > From: owner-ietf-announce@ietf.org=20 > [mailto:owner-ietf-announce@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Thursday, December 04, 2003 5:27 AM > To: IETF-Announce: > Subject: I-D ACTION:draft-vijay-dhc-dhcpv6-ipv6trans-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : DHCPv6 support for IPv6 Transition > Author(s) : a. Vijayabhaskar > Filename : draft-vijay-dhc-dhcpv6-ipv6trans-00.txt > Pages : 5 > Date : 2003-12-3 > =09 > For the newly deployed IPv6 networks to interoperate with=20 > vastly deployed IPv4 networks, various transition mechanisms=20 > had been proposed. One such mechanism is configured tunnels.=20 > This document provides a mechanism by which the DHCPv6=20 > servers can provide information about the various configured=20 > tunnel end points to reach the IPv6 nodes which are separated=20 > by IPv4 networks. >=20 > A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-ipv6trans-00. txt To remove yourself from the IETF Announcement list, send a message to=20 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-vijay-dhc-dhcpv6-ipv6trans-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-vijay-dhc-dhcpv6-ipv6trans-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 8 11:05:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15860; Mon, 8 Dec 2003 11:05:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATNsc-0004qv-6C; Mon, 08 Dec 2003 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATNsV-0004qa-DG for dhcwg@optimus.ietf.org; Mon, 08 Dec 2003 11:04:55 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15841 for ; Mon, 8 Dec 2003 11:04:37 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ATNr2-0008GK-J3; Mon, 08 Dec 2003 11:03:24 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 08 Dec 2003 11:03:24 -0500 Subject: [dhcwg] Last Call: 'DHCP Lease Query' 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 WG to consider the following document: - 'DHCP Lease Query' 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-12-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-06.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 8 11:50:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15861; Mon, 8 Dec 2003 11:05:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATNsd-0004rF-Ab; Mon, 08 Dec 2003 11:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATNsX-0004qg-AU for dhcwg@optimus.ietf.org; Mon, 08 Dec 2003 11:04:57 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15844 for ; Mon, 8 Dec 2003 11:04:39 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ATNsN-0008JN-Ii; Mon, 08 Dec 2003 11:04:47 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 08 Dec 2003 11:04:47 -0500 Subject: [dhcwg] Last Call: 'Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB' 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 WG to consider the following document: - 'Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB' 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-12-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-09.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Dec 9 15:06:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11292; Tue, 9 Dec 2003 15:06:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATo7N-0005Yv-G7; Tue, 09 Dec 2003 15:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATo6n-0005Y4-Mg for dhcwg@optimus.ietf.org; Tue, 09 Dec 2003 15:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11123; Tue, 9 Dec 2003 15:05:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATo6k-0006hK-00; Tue, 09 Dec 2003 15:05:22 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1ATo6j-0006hH-00; Tue, 09 Dec 2003 15:05:21 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hB9K5Ls20832; Tue, 9 Dec 2003 12:05:21 -0800 (PST) Message-Id: <200312092005.hB9K5Ls20832@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 09 Dec 2003 12:05:21 -0800 Subject: [dhcwg] RFC 3646 on DNS Configuration options for Dynamic Host 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 Request for Comments is now available in online RFC libraries. RFC 3646 Title: DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s): R. Droms, Ed. Status: Standards Track Date: December 2003 Mailbox: rdroms@cisco.com Pages: 7 Characters: 13312 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3646.txt This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031209120354.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3646 --OtherAccess Content-Type: Message/External-body; name="rfc3646.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031209120354.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 15 13:31:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19362; Mon, 15 Dec 2003 13:31:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxUl-0008N1-It; Mon, 15 Dec 2003 13:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxUa-0008MH-De for dhcwg@optimus.ietf.org; Mon, 15 Dec 2003 13:30:52 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19313 for ; Mon, 15 Dec 2003 13:30:48 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AVxU0-0004hY-D6; Mon, 15 Dec 2003 13:30:16 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 15 Dec 2003 13:30:16 -0500 Subject: [dhcwg] Last Call: 'Simple Network Time Protocol Configuration Option 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 WG to consider the following document: - 'Simple Network Time Protocol Configuration Option 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-12-31. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-sntp-00.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Dec 16 10:25:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17301; Tue, 16 Dec 2003 10:25:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWH4N-0004Nw-Cv; Tue, 16 Dec 2003 10:25:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWH3s-0004IT-Ha for dhcwg@optimus.ietf.org; Tue, 16 Dec 2003 10:24:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17158 for ; Tue, 16 Dec 2003 10:24:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWH3p-0003r4-00 for dhcwg@ietf.org; Tue, 16 Dec 2003 10:24:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWFgq-0002q5-00 for dhcwg@ietf.org; Tue, 16 Dec 2003 08:56:45 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AWFWz-0002kz-00; Tue, 16 Dec 2003 08:46:33 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hBGDjaQe011777; Tue, 16 Dec 2003 14:45:36 +0100 Date: Tue, 16 Dec 2003 14:45:34 +0100 From: Henrik Levkowetz To: mip4@ietf.org, dhcwg@ietf.org Cc: Ralph Droms , Pete McCann Message-Id: <20031216144534.5d485c53.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__16_Dec_2003_14_45_34_+0100_KBASx0=0_HU1EBA5" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [dhcwg] Runthrough of issues raised on draft-ietf-dhc-mipadvert-opt-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: , --Signature=_Tue__16_Dec_2003_14_45_34_+0100_KBASx0=0_HU1EBA5 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, I've gone through the comments given on this draft as a result of the WG last call. The issues have been recorded in an issue tracker at http://www.mip4.org/issues/tracker/mip4/ , and the proposed resolution for each of the issues raised can be seen in the working documents I maintain at http://ietf.levkowetz.com/drafts/dhc/mipadvert/ , as well as in the issue tracker. I'd much appreciate feedback on the proposed resolutions. See the list below for the individual issues, and link to proposed text. The full text of the current incarnation of the working document, with all the proposed fixes applied, is at: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.n.txt Henrik --- Issue Details 28 Title: How does the DHCP server know about agent load? From: Kuntal Chowdhury Issue: http://www.mip4.org/issues/tracker/mip4/issue28 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.a-from-01.diff.html 29 Title: 'B' bit may not always be valid From: Kuntal Chowdhury Issue: http://www.mip4.org/issues/tracker/mip4/issue29 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.b-from-02.a.diff.html 30 Title: Precise rules for sending and receiving these options needed. From: Ralph Droms , Alpesh Patel Issue: http://www.mip4.org/issues/tracker/mip4/issue30 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.c-from-02.b.diff.html 31 Title: Handling of sequence number field From: Naveen Paulkandasamy , Thomas Narten and others Issue: http://www.mip4.org/issues/tracker/mip4/issue31 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.d-from-02.c.diff.html 32 Title: Zero-length suboptions From: Kim Kinnear , Bernie Volz , Ted Lemon , Eric.Luce@nominum.com Issue: http://www.mip4.org/issues/tracker/mip4/issue32 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.e-from-02.d.diff.html 33 Title: Add request to IANA to maintain registry for sub-options From: Ralph Droms , Alpesh Patel Issue: http://www.mip4.org/issues/tracker/mip4/issue33 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.f-from-02.e.diff.html 34 Title: AD comments, with bearing on issues 29, 30, 33, plus nits From: Thomas Narten Issue: http://www.mip4.org/issues/tracker/mip4/issue34 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.g-from-02.f.diff.html 36 Title: Duplication of 3344 advertisement format specification & 1 nit From: Sami Vaarala , Espen Klovning Issue: http://www.mip4.org/issues/tracker/mip4/issue36 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.h-from-02.g.diff.html 37 Title: How should MN use this option? From: Espen Klovning" Issue: http://www.mip4.org/issues/tracker/mip4/issue37 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.i-from-02.h.diff.html 38 Title: Must the Agents be on-link? From: Pete McCann Issue: http://www.mip4.org/issues/tracker/mip4/issue38 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.j-from-02.i.diff.html 39 Title: Nits From: Ralph Droms Issue: http://www.mip4.org/issues/tracker/mip4/issue39 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.k-from-02.j.diff.html 40 Title: How to select the individual agent assignments From: Alpesh Patel , Naveen Paulkandasamy , Issue: http://www.mip4.org/issues/tracker/mip4/issue40 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.l-from-02.k.diff.html 41 Title: How does this option tie into authentication of DHCP messages From: Alpesh Patel Issue: http://www.mip4.org/issues/tracker/mip4/issue41 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.m-from-02.l.diff.html 42 Title: Tying NAI and ciaddr fields together From: Alpesh Patel Issue: http://www.mip4.org/issues/tracker/mip4/issue42 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.n-from-02.m.diff.html --Signature=_Tue__16_Dec_2003_14_45_34_+0100_KBASx0=0_HU1EBA5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/3wx+eVhrtTJkXCMRAvL4AJ9nN4YmoP9cFwBNswh3yvMtNYlbTwCglvBn a3SBRn4EaUFd+tm4avWBuVc= =B9cz -----END PGP SIGNATURE----- --Signature=_Tue__16_Dec_2003_14_45_34_+0100_KBASx0=0_HU1EBA5-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From bkdinfo@mail.com Wed Dec 17 17:56:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10637 for ; Wed, 17 Dec 2003 17:56:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWkao-0006kd-00 for dhc-archive@ietf.org; Wed, 17 Dec 2003 17:56:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWkam-0006kV-00 for dhc-archive@ietf.org; Wed, 17 Dec 2003 17:56:33 -0500 Received: from c-67-164-99-139.client.comcast.net ([67.164.99.139] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AWkaU-0006ik-00; Wed, 17 Dec 2003 17:56:15 -0500 From: "Temas Patrulhados" To: dccp-request@ietf.org Subject: Lindenberg: Emprego rural versus assentamentos ref.: qfj X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Wed, 17 Dec 2003 17:56:15 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.3 required=5.0 tests=FORGED_MUA_EUDORA,HTML_40_50, HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora

plw ConstruNews deseja a todos um feliz Natal! EnEspañol - InEnglish - Subscrever - Remover

Série Temas Patrulhados

Lindenberg: Emprego rural versus assentamentos

"Por que os agrorreformistas só falam em assentamentos e nunca na criação de empregos na área rural?"

* Patrulhamento

Adolpho Lindenberg é autor do livro Os católicos e a economia de mercado", onde denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, opiniões e livros "politicamente incorretos", não afinados com as assim denominadas "causas sociais": os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Agrorreformistas

Em artigo "Emprego rural versus assentamentos", da Série Temas Patrulhados, Lindenberg pergunta:

- Por que os agrorreformistas só falam em assentamentos e nunca na criação de empregos na área rural?

- Por que não reivindicam financiamentos ou outros estímulos à agroindústria ou a empresas rurais que empregam grande número de trabalhadores?

- Por que não propõem modificações na legislação trabalhista para o campo de modo a permitir que os fazendeiros reconstruam as antigas colônias com casas razoáveis e terrenos destinados ao plantio de hortaliças, criação de porcos e galinhas etc.?

* Viés socialista

A resposta do autor é simples:

- Trata-se do velho viés marxista, a mentalidade socialista, denominador comum a todos os agrorreformistas! Na mentalidade marxista, o patrão é sempre visto como um explorador e o empregado como um semiescravo, humilhado e indefeso! Para pessoas de mentalidade esquerdista, o contraste entre o casario pobre de uma colônia e o casarão senhorial do fazendeiro, lembra feudalismo, desigualdade social gritante, injustiças de toda espécie. Xico Graziano, ex-presidente do Incra, confirma essa obsessão niveladora ao atribuir o desinteresse dos agrorreformistas pela qualidade e pelo custo da política de assentamentos "a uma razão de fundo ideológico, pois o pensamento agrarista tradicional sempre se interessou em penalizar o latifúndio, desapropriando-o".

* Sonho aliciante

Haverá um sonho mais aliciante e semelhante ao velho utopismo socialista, do que um país onde todos têm sua terra para plantar, financiamentos com juros subsidiados, onde não existem patrões ou fiscais de qualquer espécie?, pergunta Lindenberg em seu artigo. E responde: Diante desse sonho utópico, o único recurso que nos resta é o apelo constante ao bom senso e à experiência acumulada durante séculos. De um modo muito empírico, quase a título exemplificativo, poder-se-ia alinhar algumas considerações atinentes à problemática:

- A condição empregatícia de si não tem absolutamente nada de humilhante ou de exploratório. As mais altas autoridades do país - o presidente, os ministros, magistrados do Supremo - são empregados. São igualmente empregados os professores, os oficiais superiores, os altos executivos que governam os grandes conglomerados econômicos e as multinacionais.

- O importante para o trabalhador rural não é ser o dono da terra, como também para o morador de uma casa não é ser dono do imóvel. O importante é ganhar bem, poder progredir, sentir-se seguro no emprego, estar em condições de formar um pecúlio. Dono de um capital, o empregado pode decidir se compra a terra ou a casa, ou se investe num negócio ou se compra ações. Ele se tornou um minicapitalista.

- Aliás, diga-se de passagem, o Brasil só terá se tornado um país verdadeiramente capitalista na medida em que boa parte de sua população seja proprietária de minicapitais. A esse respeito convém lembrar o exemplo dado pelos imigrantes japoneses. Considerados os agricultores mais bem sucedidos que já aportaram em nossas terras, eles sempre preferiram arrendar a comprar as várzeas nas quais plantaram suas hortas e isso com um sucesso absoluto.

- Que haja uma significativa diminuição do desemprego e do êxodo rural constitui um anseio nacional. Que os homens do campo, pequenos proprietários, assentados, bóias-frias consigam elevar seus padrões de vida a níveis aceitáveis constitui, igualmente uma meta a ser atingida. Esses objetivos não são, por conseguinte um monopólio dos agrorreformistas e, muito menos, um apanágio das esquerdas. No modo de solucionar essas carências é que se situam as diferenças.

* Outros temas

Outros temas abordados no artigo: Monteiro Lobato, a saúva e o sítio; condições para o éxito das pequenas propriedades; causas do enfraquecimento dos "liames feudais" entre fazendeiros e empregados; os descontentes e o "canto de sereia" dos agrorreformistas; o crescimento espetacular dos Tigres Asiáticos; os dois paradigmas básicos para o Brasil rural; e como evitar, no Brasil, o triunfo da utopia e da revolução social. Para receber gratuitamente o texto completo deste artigo, clique em: Lindenberg:DesejoReceberGratuitamenteEsteArtigo

LINKS DE OPINIÃO:

Entre aqueles que enviarem sua valiosa opinião a respeito do texto acima, até 31 de dezembro, usando qualquer um dos links seguintes, serão sorteados 10 exemplares impressos do livro "Os católicos e a economia de mercado". Os favorecidos serão comunicados por e-mail e deverão enviar o endereço postal para receberem os exemplares do livro, por Correio).

Lindenberg:Concordo (pode simplesmente enviar seu voto virtual, e acrescentar seu comentário caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirE-Book (para adquirir o livro, em formato Word, que será enviado por e-mail; clicando neste link receberá número de conta bancária para efetuar transferência; preço promocional do e-book, até 31 de dezembro: R$ 5,50)

Lindenberg:DesejoAdquirirLivroEmPortugal (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora em Portugal; preço: E 19,45)

Lindenberg:DesejoAdquirirLivroNoBrasil (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora no Brasil, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais Correio)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores

GratuitamenteProximosArtigos

GratuitamenteTodosOsArtigos

LINK DE REMOÇÃO

ConstruNews:Remover

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 From dhcwg-admin@ietf.org Wed Dec 17 18:21:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13504; Wed, 17 Dec 2003 18:21:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWkyU-0004by-Qo; Wed, 17 Dec 2003 18:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWkxc-0004Xy-2d for dhcwg@optimus.ietf.org; Wed, 17 Dec 2003 18:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13423 for ; Wed, 17 Dec 2003 18:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWkxZ-0000Ib-00 for dhcwg@ietf.org; Wed, 17 Dec 2003 18:20:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWkxW-0000IH-00 for dhcwg@ietf.org; Wed, 17 Dec 2003 18:20:04 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AWkxV-0000Db-00 for dhcwg@ietf.org; Wed, 17 Dec 2003 18:20:01 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HQ200901BGDNF@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 18 Dec 2003 08:19:25 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HQ200A8JBGD32@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 18 Dec 2003 08:19:25 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HQ200KZ3BGCQZ@mmp1.samsung.com> for dhcwg@ietf.org; Thu, 18 Dec 2003 08:19:24 +0900 (KST) Date: Thu, 18 Dec 2003 08:20:01 +0900 From: Soohong Daniel Park To: dhcwg@ietf.org Cc: "'Soohong Daniel Park'" , "'Vijayabhaskar A K'" Message-id: <007a01c3c4f4$4ba33f80$b7cbdba8@daniel> 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/mixed; boundary="Boundary_(ID_c/RyKl3xAHRsmO+Ak3V1RQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] FW: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-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 is a multi-part message in MIME format. --Boundary_(ID_c/RyKl3xAHRsmO+Ak3V1RQ) Content-type: multipart/alternative; boundary="Boundary_(ID_Llp8Rp4XQxubFZ6k2QfeOg)" --Boundary_(ID_Llp8Rp4XQxubFZ6k2QfeOg) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT "DHCPv6 support for IPv6 Transition" draft is changed to "Configured Tunnel End Point Option for DHCPv6" because this draft focuses on the CTEP Option to provide information about the various configured tunnel end points to reach the IPv6 nodes which are separated by IPv4 networks. Welcomes any comments Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, December 18, 2003 5:34 AM > To: IETF-Announce: > Subject: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Configured Tunnel End Point Option for DHCPv6 > Author(s) : S. Park > Filename : draft-daniel-dhc-dhcpv6-ctep-opt-00.txt > Pages : 6 > Date : 2003-12-17 > > For the newly deployed IPv6 networks to interoperate with vastly > deployed IPv4 networks, various transition mechanisms had been > proposed. One such mechanism is configured tunnels. This document > provides a mechanism by which the DHCPv6 servers can provide > information about the various configured tunnel end points to reach > the IPv6 nodes which are separated by IPv4 networks. > > A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-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-daniel-dhc-dhcpv6-ctep-opt-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-daniel-dhc-dhcpv6-ctep-opt-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. --Boundary_(ID_Llp8Rp4XQxubFZ6k2QfeOg) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT FW: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-00.txt

"DHCPv6 support for IPv6 Transition" draft is changed to "Configured Tunnel End Point Option for DHCPv6"
because this draft focuses on the CTEP Option to provide information about the various configured tunnel end points to reach the IPv6 nodes which are separated by IPv4 networks.

Welcomes any comments

Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics

> -----Original Message-----
> From: owner-ietf-announce@ietf.org
> [mailto:owner-ietf-announce@ietf.org] On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Thursday, December 18, 2003 5:34 AM
> To: IETF-Announce:
> Subject: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-00.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>       Title           : Configured Tunnel End Point Option for DHCPv6
>       Author(s)       : S. Park
>       Filename        : draft-daniel-dhc-dhcpv6-ctep-opt-00.txt
>       Pages           : 6
>       Date            : 2003-12-17
>      
> For the newly deployed IPv6 networks to interoperate with vastly 
> deployed IPv4 networks, various transition mechanisms had been
> proposed.  One such mechanism is configured tunnels.  This document
> provides a mechanism by which the DHCPv6 servers can provide
> information about the various configured tunnel end points to reach
> the IPv6 nodes which are separated by IPv4 networks.
>
> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-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-daniel-dhc-dhcpv6-ctep-opt-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-daniel-dhc-dhcpv6-ctep-opt-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. <<...>> <<...>>

--Boundary_(ID_Llp8Rp4XQxubFZ6k2QfeOg)-- --Boundary_(ID_c/RyKl3xAHRsmO+Ak3V1RQ) Content-type: Message/External-body; name=ATT00063.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00063.dat Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-17151859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-00.txt --Boundary_(ID_c/RyKl3xAHRsmO+Ak3V1RQ) Content-type: Message/External-body; name=draft-daniel-dhc-dhcpv6-ctep-opt-00.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-daniel-dhc-dhcpv6-ctep-opt-00.txt Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-17151859.I-D@ietf.org> --Boundary_(ID_c/RyKl3xAHRsmO+Ak3V1RQ)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 18 10:37:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29512; Thu, 18 Dec 2003 10:37:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0D0-0008Qg-Ed; Thu, 18 Dec 2003 10:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Ck-0008Q4-2T for dhcwg@optimus.ietf.org; Thu, 18 Dec 2003 10:36:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29441 for ; Thu, 18 Dec 2003 10:36:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0Ch-00022Q-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 10:36:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0Cg-00022J-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 10:36:43 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by ietf-mx with esmtp (Exim 4.12) id 1AX0Cg-000223-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 10:36:42 -0500 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 3386596 for dhcwg@ietf.org; Thu, 18 Dec 2003 16:36:16 +0100 From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Date: Thu, 18 Dec 2003 16:39:15 +0100 User-Agent: KMail/1.5.4 References: <007a01c3c4f4$4ba33f80$b7cbdba8@daniel> In-Reply-To: <007a01c3c4f4$4ba33f80$b7cbdba8@daniel> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312181639.15256.budm@weird-solutions.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] List traffic? 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 Has the traffic died down on this list in the last week or so, or is there a problem? I'm not getting much activity... - Bud Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 18 15:30:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15071; Thu, 18 Dec 2003 15:30:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4mZ-0006BC-2V; Thu, 18 Dec 2003 15:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4m0-00066P-FS for dhcwg@optimus.ietf.org; Thu, 18 Dec 2003 15:29:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14854; Thu, 18 Dec 2003 15:29:26 -0500 (EST) Message-Id: <200312182029.PAA14854@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, 18 Dec 2003 15:29:25 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subscriber-id-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 : DHCP Subscriber ID Suboption for the DHCP Relay Agent Option Author(s) : R. Johnson, R. Droms Filename : draft-ietf-dhc-subscriber-id-04.txt Pages : 8 Date : 2003-12-18 This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable 'Subscriber-ID' with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-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-subscriber-id-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-subscriber-id-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-12-18142559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subscriber-id-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subscriber-id-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142559.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 Dec 18 18:33:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28331; Thu, 18 Dec 2003 18:33:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX7dd-0007lJ-HQ; Thu, 18 Dec 2003 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX7cm-0007ko-2i for dhcwg@optimus.ietf.org; Thu, 18 Dec 2003 18:32:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28290 for ; Thu, 18 Dec 2003 18:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX7cj-00008O-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 18:32:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX7ch-00008H-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 18:32:04 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AX7ch-00007b-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 18:32:03 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HQ400A016OF7C@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 19 Dec 2003 08:31:27 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HQ400HSV6OFGY@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 19 Dec 2003 08:31:27 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HQ400M5D6OEMN@mmp1.samsung.com> for dhcwg@ietf.org; Fri, 19 Dec 2003 08:31:27 +0900 (KST) Date: Fri, 19 Dec 2003 08:32:04 +0900 From: Soohong Daniel Park In-reply-to: To: "'Pekka Savola'" Cc: vijayak@india.hp.com, dhcwg@ietf.org, "'Soohong Daniel Park'" Message-id: <00c801c3c5bf$25563d20$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] RE: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-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: , Content-Transfer-Encoding: 7BIT > First, I'm not sure whether this option even makes much > sense, but I'm > not commenting on that at the moment. We have tried to address why this option is required in introduction section. 1. Introduction In the initial deployment of IPv6, the IPv6 nodes may need to communicate with the other IPv6 nodes via IPv4 networks. Configured tunnels [3] provide a way to encapsulate the IPv6 packets in IPv4 packets and tunnel them in the IPv4 network. This document defines a new option called Configured Tunnel End Point by which the DHCPv6 [1] server can notify the client with the list of end point of the configured tunnels to the various IPv6 networks separated by the IPv4 networks. Not enough ? or need text improvement ? Note that this draft is only proposing CTEP option not newly defined mechanism. > Important comments: > =================== > > 1) the spec does not elaborate at all how the tunnel > end-point is going to configure the IP address of the node > (because the configured tunnel must be configured somehow at > the tunnel-end someone as well). > This is of course easy if coupled to DHCPv6 address > assignment and is done as part of the DHCP process at the > server, but otherwise it could be a bit trickier. > > The details are probably outside the scope of this specification, but > the complexity must be explicitly spelled out IMHO. Well, most draft and rfc about dhcp options just address each option not detail procedure. However we will consider how we can express it more clear... > 2) The document talks about "various IPv6 networks which are > separated > by IPv4 networks", but the tunnel end-point address is still an IPv6 > address. > > There is a mismatch there; either the endpoint must be v4 > address, the > text must be changed, or this option should provide for the > possibility of either v6-in-v4 or v6-in-v4 (or even v4-in-v6) tunnels. I see. > 3) The IPR notice is totally wrong: > > Notice Regarding Intellectual Property Rights > > See > http://www.ietf.org/ietf/IPR/samsung-general-patent04102003.txt > > .. is this meant to say that Samsung has claimed some IPR about this > option? In this case, they must submit a separate IPR disclaimer at > www.ietf.org/ipr, the above is not correct. Moreover, it's > incorrect to refer to the claims directly. Replace this section with: > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any > assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this > specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > ... and if IPR has been claimed (but not filed yet), also add at the > end: > > The IETF has been notified of intellectual property rights > claimed in regard to some or all of the specification contained > in this document. For more information consult the online list > of claimed rights. replaced with 01 version. it is my habitual format. > Nits: > ===== > > Destination Prefix: IPv6 Prefix; > > ==> s/IPv6 Prefix;/An IPv6 prefix./ Ok. > Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. The idea of this specification is based on > RFC 2937, September 2000. Thanks to the DHC Working > Group for their > time and input into the specification. In particular, thanks to > Pekka Savola, Bernie Volz, Ralph Droms, for their > valuable comments > on this work. > > ==> this section couples two separate sections, the "RFC-Editor/ISOC" > acknowledgement, and acknowledgement about this document. > They should > be separated, the latter parts put in a section of their own e.g. > before the References section. > ditto. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 18 23:18:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10087; Thu, 18 Dec 2003 23:18:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXC5Q-0004ib-Uu; Thu, 18 Dec 2003 23:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWc9d-00035W-Ro for dhcwg@optimus.ietf.org; Wed, 17 Dec 2003 08:55:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07516 for ; Wed, 17 Dec 2003 08:55:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWc9c-0003fc-00 for dhcwg@ietf.org; Wed, 17 Dec 2003 08:55:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWc9b-0003fV-00 for dhcwg@ietf.org; Wed, 17 Dec 2003 08:55:56 -0500 Received: from akivas.pacific.net.sg ([203.120.90.214]) by ietf-mx with smtp (Exim 4.12) id 1AWc9a-0003dR-00 for dhcwg@ietf.org; Wed, 17 Dec 2003 08:55:55 -0500 Received: (qmail 14692 invoked from network); 17 Dec 2003 13:55:16 -0000 X-Scanned: By Symantec Anti-Virus Scan Engine Received: from unknown (HELO maxwell6.pacific.net.sg) (203.120.90.212) by akivas with SMTP; 17 Dec 2003 13:55:16 -0000 Received: from pacific.net.sg ([202.156.54.203]) by maxwell6.pacific.net.sg with ESMTP id <20031217135516.KVCI1209.maxwell6.pacific.net.sg@pacific.net.sg> for ; Wed, 17 Dec 2003 21:55:16 +0800 Message-ID: <3FE060C0.8000901@pacific.net.sg> Date: Wed, 17 Dec 2003 21:57:20 +0800 From: JH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] giaddr field in DHCPREQUEST message 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 In the rfc2131 page 23, it stated that : If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. It also stated the following in page 32: DHCPREQUEST generated during RENEWING statev: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client. Does this statement implys that the client should use unicast and send the DHCPREQUEST message directly to the DHCP server and giaddr field should be zero? At the same page: DHCPREQUEST generated during REBINDING state: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message MUST be broadcast to the 0xffffffff IP broadcast address. The DHCP server SHOULD check 'ciaddr' for correctness before replying to the DHCPREQUEST. If there is a relay agent between the client and server, is the relay agent supposed to send unicast to the server and giaddr is filled with relay address? Thank you. Ji Hui _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 18 23:46:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11072; Thu, 18 Dec 2003 23:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXCWX-0005g1-K2; Thu, 18 Dec 2003 23:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXCVs-0005fD-TW for dhcwg@optimus.ietf.org; Thu, 18 Dec 2003 23:45:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11034 for ; Thu, 18 Dec 2003 23:45:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXCVq-0004Q1-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 23:45:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXCVp-0004Pu-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 23:45:18 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AXCVp-0004PT-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 23:45:17 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HQ40020FL6H9K@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 19 Dec 2003 13:44:41 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HQ400E4YL67N8@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 19 Dec 2003 13:44:32 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HQ400M9DL67PW@mmp1.samsung.com> for dhcwg@ietf.org; Fri, 19 Dec 2003 13:44:31 +0900 (KST) Date: Fri, 19 Dec 2003 13:45:09 +0900 From: Soohong Daniel Park Subject: RE: [dhcwg] giaddr field in DHCPREQUEST message In-reply-to: <3FE060C0.8000901@pacific.net.sg> To: "'JH'" , dhcwg@ietf.org Message-id: <001401c3c5ea$e20121d0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 > In the rfc2131 page 23, it stated that : > > If the 'giaddr' field in a DHCP message from a client is non-zero, > the server sends any return messages to the 'DHCP server' > port on the > BOOTP relay agent whose address appears in 'giaddr'. > > It also stated the following in page 32: > DHCPREQUEST generated during RENEWING statev: > > 'server identifier' MUST NOT be filled in, 'requested > IP address' > option MUST NOT be filled in, 'ciaddr' MUST be filled in with > client's IP address. In this situation, the client is completely > configured, and is trying to extend its lease. This message will > be unicast, so no relay agents will be involved in its > transmission. Because 'giaddr' is therefore not filled in, the > DHCP server will trust the value in 'ciaddr', and use it when > replying to the client. > > Does this statement implys that the client should use unicast > and send the DHCPREQUEST message directly to the DHCP server and > giaddr field should be zero? Yes. > At the same page: > DHCPREQUEST generated during REBINDING state: > > 'server identifier' MUST NOT be filled in, 'requested > IP address' > option MUST NOT be filled in, 'ciaddr' MUST be filled in with > client's IP address. In this situation, the client is completely > configured, and is trying to extend its lease. This message MUST > be broadcast to the 0xffffffff IP broadcast address. The DHCP > server SHOULD check 'ciaddr' for correctness before replying to > the DHCPREQUEST. > > If there is a relay agent between the client and server, is > the relay agent supposed to > send unicast to the server and giaddr is filled with relay address? Yes. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 19 00:03:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10088; Thu, 18 Dec 2003 23:18:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXC5R-0004ij-Ms; Thu, 18 Dec 2003 23:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3Lk-0001dY-Or for dhcwg@optimus.ietf.org; Thu, 18 Dec 2003 13:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08608 for ; Thu, 18 Dec 2003 13:58:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3Li-0001i0-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 13:58:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3Lf-0001hb-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 13:58:14 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3Lf-0001bd-00 for dhcwg@ietf.org; Thu, 18 Dec 2003 13:58:11 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hBIInYC22345; Thu, 18 Dec 2003 20:49:34 +0200 Date: Thu, 18 Dec 2003 20:49:34 +0200 (EET) From: Pekka Savola To: soohong.park@samsung.com cc: vijayak@india.hp.com, In-Reply-To: <200312172033.PAA02224@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] Re: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-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: , Hi, A couple of comments. On Wed, 17 Dec 2003 Internet-Drafts@ietf.org wrote: > Title : Configured Tunnel End Point Option for DHCPv6 > Author(s) : S. Park > Filename : draft-daniel-dhc-dhcpv6-ctep-opt-00.txt > Pages : 6 > Date : 2003-12-17 > > For the newly deployed IPv6 networks to interoperate with vastly > deployed IPv4 networks, various transition mechanisms had been > proposed. One such mechanism is configured tunnels. This document > provides a mechanism by which the DHCPv6 servers can provide > information about the various configured tunnel end points to reach > the IPv6 nodes which are separated by IPv4 networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-00.txt First, I'm not sure whether this option even makes much sense, but I'm not commenting on that at the moment. Important comments: =================== 1) the spec does not elaborate at all how the tunnel end-point is going to configure the IP address of the node (because the configured tunnel must be configured somehow at the tunnel-end someone as well). This is of course easy if coupled to DHCPv6 address assignment and is done as part of the DHCP process at the server, but otherwise it could be a bit trickier. The details are probably outside the scope of this specification, but the complexity must be explicitly spelled out IMHO. 2) The document talks about "various IPv6 networks which are separated by IPv4 networks", but the tunnel end-point address is still an IPv6 address. There is a mismatch there; either the endpoint must be v4 address, the text must be changed, or this option should provide for the possibility of either v6-in-v4 or v6-in-v4 (or even v4-in-v6) tunnels. 3) The IPR notice is totally wrong: Notice Regarding Intellectual Property Rights See http://www.ietf.org/ietf/IPR/samsung-general-patent04102003.txt .. is this meant to say that Samsung has claimed some IPR about this option? In this case, they must submit a separate IPR disclaimer at www.ietf.org/ipr, the above is not correct. Moreover, it's incorrect to refer to the claims directly. Replace this section with: Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. ... and if IPR has been claimed (but not filed yet), also add at the end: The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Nits: ===== Destination Prefix: IPv6 Prefix; ==> s/IPv6 Prefix;/An IPv6 prefix./ Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. The idea of this specification is based on RFC 2937, September 2000. Thanks to the DHC Working Group for their time and input into the specification. In particular, thanks to Pekka Savola, Bernie Volz, Ralph Droms, for their valuable comments on this work. ==> this section couples two separate sections, the "RFC-Editor/ISOC" acknowledgement, and acknowledgement about this document. They should be separated, the latter parts put in a section of their own e.g. before the References section. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 19 12:04:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16019; Fri, 19 Dec 2003 12:04:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXO2i-0001fF-Tt; Fri, 19 Dec 2003 12:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXO1r-0001WA-SG for dhcwg@optimus.ietf.org; Fri, 19 Dec 2003 12:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15927 for ; Fri, 19 Dec 2003 12:03:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXO1q-000111-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 12:03:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXO1k-00010o-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 12:03:01 -0500 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1AXO1i-000105-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 12:02:59 -0500 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBJH2H19192024 for ; Fri, 19 Dec 2003 12:02:17 -0500 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id hBJH2Gvl119786 for ; Fri, 19 Dec 2003 10:02:16 -0700 Received: from login-2.austin.ibm.com (login-2.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id hBJH2GR2044490 for ; Fri, 19 Dec 2003 11:02:16 -0600 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by login-2.austin.ibm.com (AIX4.3/8.9.3p2/8.7-client1.01) with ESMTP id LAA39688 for ; Fri, 19 Dec 2003 11:00:50 -0600 Message-ID: <3FE32F16.F09A5F83@austin.ibm.com> Date: Fri, 19 Dec 2003 11:02:15 -0600 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] RFC 3315 - Vendor Specific Information 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: , Content-Transfer-Encoding: 7bit The rfc says the following This option is used by clients and servers to exchange vendor-specific information. Does this mean the client can send this options as part of Solicit, Request ....? If yes. How will server use this info ? Thanks Vasu Vallabhaneni _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 19 12:32:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16987; Fri, 19 Dec 2003 12:32:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOTq-0003BS-EH; Fri, 19 Dec 2003 12:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOTY-0003Ah-OE for dhcwg@optimus.ietf.org; Fri, 19 Dec 2003 12:31:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16944 for ; Fri, 19 Dec 2003 12:31:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXOTX-0001sq-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 12:31:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXOTV-0001sj-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 12:31:42 -0500 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1AXOTV-0001qw-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 12:31:41 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBJHV919414198 for ; Fri, 19 Dec 2003 12:31:09 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id hBJHV8ve131768 for ; Fri, 19 Dec 2003 10:31:08 -0700 Received: from login-2.austin.ibm.com (login-2.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id hBJHV7eR058040 for ; Fri, 19 Dec 2003 11:31:08 -0600 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by login-2.austin.ibm.com (AIX4.3/8.9.3p2/8.7-client1.01) with ESMTP id LAA65292 for ; Fri, 19 Dec 2003 11:29:41 -0600 Message-ID: <3FE335DA.4507F272@austin.ibm.com> Date: Fri, 19 Dec 2003 11:31:07 -0600 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,SUBJ_ALL_CAPS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] RFC - 3315 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 When the client sends a solicit packet to multicast address in a subnet where there are two or more routers which are configured to relay the message to same dhcp server but the router's have different site local address. In this scenario how should the server behave ? 1) Should it respond with Advertise for both the packets ? if yes ? How will client choose which one to select ? 2) Should respond to one of the solicit packet if yes ? How will it choose which one ? Thanks Vasu Vallabhaneni _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 19 16:24:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27825; Fri, 19 Dec 2003 16:24:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6V-0003nj-1S; Fri, 19 Dec 2003 16:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRiB-0002rS-Pj for dhcwg@optimus.ietf.org; Fri, 19 Dec 2003 15:59:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26149 for ; Fri, 19 Dec 2003 15:59:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXRiA-0001ni-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 15:59:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXRi9-0001na-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 15:59:01 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AXRi9-0001nX-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 15:59:01 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hBJKwp57035888; Fri, 19 Dec 2003 15:59:00 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Vasu, Vallabhaneni'" , Subject: RE: [dhcwg] RFC 3315 - Vendor Specific Information Option Date: Fri, 19 Dec 2003 15:59:12 -0500 Message-ID: <000601c3c672$f78c6310$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3FE32F16.F09A5F83@austin.ibm.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 See appendix A in RFC 3315 - Vendor Specific option is allowed in all but the Reconfigure message. It is vendor specific how this would be processed by the server (and client). A client might send a vendor-specific option with a specific enterprise value and a "vendor-specific Option Request Option" in that vendor-specific option. The server might then send back those requested options encapsulated within the vendor-specific option. Vendor specific options are no different than standard (publicly) assigned options but instead of these options having to be defined through the IETF process, the vendor can do it on its own. Clients and servers that wish to support these options could then be developed. The option number space of the encapsulated options (in the vendor-specific option) are up to the vendor to manage. And, if they want server vendors to implement these options, they should make the documentation on these options available. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Vasu, Vallabhaneni Sent: Friday, December 19, 2003 12:02 PM To: dhcwg@ietf.org Subject: [dhcwg] RFC 3315 - Vendor Specific Information Option The rfc says the following This option is used by clients and servers to exchange vendor-specific information. Does this mean the client can send this options as part of Solicit, Request ....? If yes. How will server use this info ? Thanks Vasu Vallabhaneni _______________________________________________ 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 Dec 19 16:50:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29059; Fri, 19 Dec 2003 16:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXSVX-0005Ot-1A; Fri, 19 Dec 2003 16:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXSVI-0005O3-99 for dhcwg@optimus.ietf.org; Fri, 19 Dec 2003 16:49:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29030 for ; Fri, 19 Dec 2003 16:49:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXSVG-0004KD-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 16:49:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXSVF-0004K5-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 16:49:45 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AXSVF-0004K2-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 16:49:45 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hBJLnY57046137; Fri, 19 Dec 2003 16:49:45 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Vasu, Vallabhaneni'" , Subject: RE: [dhcwg] RFC - 3315 Date: Fri, 19 Dec 2003 16:49:55 -0500 Message-ID: <000001c3c67a$0eaa08c0$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3FE335DA.4507F272@austin.ibm.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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 First, aren't site local addresses essentially gone (I stopped listening = to the debate a while ago ... so I don't know what was ever decided). But, I would say that the server would be configured to know that the = client was on a particular link based on EITHER site local address and would therefore consider the "second" request to be a duplicate of the first = and resend essentially the same response. Therefore, the server would = respond to both Advertises with essentially similar information. The client would = pick one of these (randomly perhaps) and send the Request. In this case, the server policy would likely be to give the client = addresses for both site locals, but that is a policy issue. If the server isn't configured to know the client is on the same link, = it really doesn't matter though then the client will get one or the other site-local address and not both. The above is really no different than the IPv4 case of having two relays = on a single link with multiple "shared subnets" active and each relay = having a giaddr in a different subnet. The DHCPv4 server would respond to both requests with an address for the client from the range of available addresses (which might be in one of the subnets or perhaps even a = third). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Vasu, Vallabhaneni Sent: Friday, December 19, 2003 12:31 PM To: dhcwg@ietf.org Subject: [dhcwg] RFC - 3315 When the client sends a solicit packet to multicast address in a subnet where there are two or more routers which are configured to relay the message to same dhcp server but the router's have different site local address. In this scenario how should the server behave ? 1) Should it respond with Advertise for both the packets ? if yes ? How will client choose which one to select ? 2) Should respond to one of the solicit packet if yes ? How will it choose which one ? Thanks Vasu Vallabhaneni _______________________________________________ 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 Sat Dec 20 18:08:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22804; Sat, 20 Dec 2003 18:08:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXqCX-0004Po-QE; Sat, 20 Dec 2003 18:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIfU-0003pL-0U for dhcwg@optimus.ietf.org; Fri, 19 Dec 2003 06:19:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04110 for ; Fri, 19 Dec 2003 06:19:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIfQ-0006RB-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 06:19:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIfP-0006R4-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 06:19:35 -0500 Received: from [193.95.181.186] (helo=MAILSWEEPER.clearstream.ie) by ietf-mx with esmtp (Exim 4.12) id 1AXIfO-0006R1-00 for dhcwg@ietf.org; Fri, 19 Dec 2003 06:19:34 -0500 Received: from ntsrvirl01.clearstream.ie (unverified) by MAILSWEEPER.clearstream.ie (Content Technologies SMTPRS 4.3.1) with ESMTP id for ; Fri, 19 Dec 2003 11:21:05 +0000 Received: by NTSRVIRL01 with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Dec 2003 11:31:20 -0000 Message-ID: <50C100CE8977D511B7E300805FCC136C8DC645@NTSRVIRL01> From: Nick Elliott To: "'dhcwg@ietf.org'" Date: Fri, 19 Dec 2003 11:31:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C623.9F89F780" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCUSE_16,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] Restricting Access using DHCP 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_01C3C623.9F89F780 Content-Type: text/plain; charset="iso-8859-1" Hi Folks, I just a have a quick question. We use DHCP on all PC's on our network with the exception of a couple of servers. However, I need to be able to restrict access on a few of these PC's so they cannot access anything outside our own network. Can anyone advise me on how to go about this. Thanks in advance, Nick. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager at ClearStream Technologies Ltd. on postmaster@clearstream.ie. This footnote also confirms that this email message has been swept for the presence of computer viruses. ********************************************************************** ------_=_NextPart_001_01C3C623.9F89F780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Restricting Access using DHCP

Hi Folks,

I just a have a quick question. We use DHC= P on all PC's on our network with the exception of a couple of servers. How= ever, I need to be able to restrict access on a few of these PC's so they c= annot access anything outside our own network. Can anyone advise me on how = to go about this.

 
Thanks in advance,

Nick.



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager at ClearStream Technologies Ltd. on postmaster@clearstre= am.ie.
This footnote also confirms that this email message has been swept for the = presence of computer viruses.
**********************************************************************
 ------_=_NextPart_001_01C3C623.9F89F780-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Dec 20 20:17:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26803; Sat, 20 Dec 2003 20:17:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXsCQ-00085C-LD; Sat, 20 Dec 2003 20:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXsC1-00082Z-Hd for dhcwg@optimus.ietf.org; Sat, 20 Dec 2003 20:15:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26580 for ; Sat, 20 Dec 2003 20:15:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXsBz-0005Md-00 for dhcwg@ietf.org; Sat, 20 Dec 2003 20:15:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXsAy-0005FG-00 for dhcwg@ietf.org; Sat, 20 Dec 2003 20:14:38 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1AXsAx-0005CO-00 for dhcwg@ietf.org; Sat, 20 Dec 2003 20:14:31 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AXsAR-0008Bc-00; Sat, 20 Dec 2003 17:13:59 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Sat, 20 Dec 2003 17:13:53 -0800 Message-ID: From: "Kostur, Andre" To: "'Nick Elliott'" , "'dhcwg@ietf.org'" Subject: RE: [dhcwg] Restricting Access using DHCP Date: Sat, 20 Dec 2003 17:13:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C75F.B29F49F0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 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_01C3C75F.B29F49F0 Content-Type: text/plain; charset="iso-8859-1" From a DHCP perspective, you'd want to configure whatever DHCP server that you're using to not give those specific PCs a default gateway (option 3). This should prevent that PC from being able to route traffic off of your network. However, if the users of those PCs can add their own routes then the problem is bigger than DHCP. You'd want to do something at your firewall to stop any traffic from those PCs. -----Original Message----- From: Nick Elliott [mailto:nelliott@clearstream.ie] Sent: Friday, December 19, 2003 3:31 AM To: 'dhcwg@ietf.org' Subject: [dhcwg] Restricting Access using DHCP Hi Folks, I just a have a quick question. We use DHCP on all PC's on our network with the exception of a couple of servers. However, I need to be able to restrict access on a few of these PC's so they cannot access anything outside our own network. Can anyone advise me on how to go about this. ------_=_NextPart_001_01C3C75F.B29F49F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Restricting Access using DHCP

From a DHCP perspective, you'd want to configure = whatever DHCP server that you're using to not give those specific PCs a = default gateway (option 3).  This should prevent that PC from = being able to route traffic off of your network.  However, if the = users of those PCs can add their own routes then the problem is bigger = than DHCP.  You'd want to do something at your firewall to stop = any traffic from those PCs.


-----Original Message-----
From: Nick Elliott [mailto:nelliott@clearstream.ie]
Sent: Friday, December 19, 2003 3:31 AM
To: 'dhcwg@ietf.org'
Subject: [dhcwg] Restricting Access using = DHCP


Hi Folks,
I just a have a quick question. We use DHCP on all = PC's on our network with the exception of a couple of servers. However, = I need to be able to restrict access on a few of these PC's so they = cannot access anything outside our own network. Can anyone advise me on = how to go about this.

 

------_=_NextPart_001_01C3C75F.B29F49F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Dec 21 13:48:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01449; Sun, 21 Dec 2003 13:48:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY8cT-0007nn-TG; Sun, 21 Dec 2003 13:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY8c0-0007nP-27 for dhcwg@optimus.ietf.org; Sun, 21 Dec 2003 13:47:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01440 for ; Sun, 21 Dec 2003 13:47:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AY8bs-00065L-00 for dhcwg@ietf.org; Sun, 21 Dec 2003 13:47:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AY8bS-00064s-00 for dhcwg@ietf.org; Sun, 21 Dec 2003 13:46:59 -0500 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 1AY8bR-00063v-00 for dhcwg@ietf.org; Sun, 21 Dec 2003 13:46:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Dec 2003 10:50:22 +0000 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 hBLIjuVM024734 for ; Sun, 21 Dec 2003 10:46:01 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-467.cisco.com [10.82.225.211]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEV03612; Sun, 21 Dec 2003 13:45:55 -0500 (EST) Message-Id: <4.3.2.7.2.20031221133312.01eaf470@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 21 Dec 2003 13:45:51 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5377041==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_RED,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateless-03.txt published 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: , --=====================_5377041==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I've submitted draft-ietf-dhc-dhcpv6-stateless-03.txt for publication. This revision includes changes in response to comments from the IESG. The most important changes are to section 5: * text that describes use of Information-request/Reply message exchange when a host moves to a new link has been deleted * text added referring to draft-ietf-dhc-dna-ipv4-04 (which addresses the problem of link attachment in IPv4) and to work on defining mechanism to control host use of Information-request/Reply message exchange (e.g., draft-chown-dhc-stateless-dhcpv6-renumbering; note that no specific drafts are cited in draft-ietf-dhc-dhcpv6-stateless-03.txt) I've included the revised section and an HTML diff of the -02 and -03 revs of draft-ietf-dhc-dhcpv6-stateless. Please respond with comments... - Ralph ===== 5. Implementation of Stateless DHCP The client indicates that it is requesting configuration information by sending an Information-request message that includes an Option Request option specifying the options that it wishes to receive from the DHCP server. For example, if the client is attempting to obtain a list of DNS recursive name servers, it identifies the DNS Recursive Name Server option in the Information-request message. The server determines the appropriate configuration parameters for the client based on its configuration policies and responds with a Reply message containing the requested parameters. In this example, the server would respond with DNS configuration parameters. As described in section 18.1.5 of RFC 3315, a node may include a Client Identifier option in the Information-request message to identify itself to a server, because the server administrator may want to customize the server's response to each node, based on the node's identity. RFC 3315 does not define any mechanisms through which the time at which a host uses an Information-request message to obtain updated configuration parameters can be controlled. The dhc WG has undertaken the development of such a mechanism or mechanisms which will be published as Standards-track RFC(s). RFC 3315 also does not provide any guidance about when a host might use an Information-request message to obtain updated configuration parameters when the host has moved to a new link. The dhc WG is reviewing a related document, "Detection of Network Attachment (DNA) in IPv4" [8], which describes how a host using IPv4 can determine when to use DHCPv4. Either the dhc WG or a WG formed from the dna BOF will undertake development of a similar document for IPv6. [8] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", draft-ietf-dhc-dna-ipv4-04 (work in progress), October 2003. ===== 5. Implementation of Stateless DHCP The client indicates that it is requesting configuration information by sending an Information-request message that includes an Option Request option specifying the options that it wishes to receive from the DHCP server. For example, if the client is attempting to obtain a list of DNS recursive name servers, it identifier identifies the DNS Recursive Name Server option in the Information-request message. The server determines the appropriate configuration parameters for the client based on its configuration policies and responds with a Reply message containing the requested parameters. In this example, the server would respond with DNS configuration parameters. A As described in section 18.1.5 of RFC 3315, a node uses the may include a Client Identifier option in the Information-request message to identify itself to a server, because the server administrator may want to customize the server's response to each node, based on the node's identity. Whenever RFC 3315 does not define any mechanisms through which the time at which a client may have moved host uses an Information-request message to a new link, the obtain updated configuration parameters obtained for the interfaces on that link may no longer can be appropriate for the link to which controlled. The dhc WG has undertaken the client is attached. Examples development of times such a mechanism or mechanisms which will be published as Standards-track RFC(s). RFC 3315 also does not provide any guidance about when a client may have host might use an Information-request message to obtain updated configuration parameters when the host has moved to a new link include: o The client reboots. o link. The client dhc WG is physically connected to reviewing a wired connection. o The client returns from sleep mode. o The client using related document, "Detection of Network Attachment (DNA) in IPv4" [8], which describes how a wireless technology changes access points. In any situation host using IPv4 can determine when a client may have moved to use DHCPv4. Either the dhc WG or a new link, WG formed from the client initiates an Information-request/Reply message exchange. dna BOF will undertake development of a similar document for IPv6. --=====================_5377041==_.ALT Content-Type: text/html; charset="us-ascii" I've submitted draft-ietf-dhc-dhcpv6-stateless-03.txt for publication.  This
revision includes changes in response to comments from the IESG.  The most
important changes are to section 5:

* text that describes use of Information-request/Reply message exchange when
  a host moves to a new link has been deleted
* text added referring to draft-ietf-dhc-dna-ipv4-04 (which addresses the
  problem of link attachment in IPv4) and to work on defining mechanism to
  control host use of Information-request/Reply message exchange (e.g.,
  draft-chown-dhc-stateless-dhcpv6-renumbering; note that no specific drafts
  are cited in draft-ietf-dhc-dhcpv6-stateless-03.txt)

I've included the revised section and an HTML diff of the -02 and -03 revs
of draft-ietf-dhc-dhcpv6-stateless.

Please respond with comments...

- Ralph

=====

   5. Implementation of Stateless DHCP

      The client indicates that it is requesting configuration
      information by sending an Information-request message that
      includes an Option Request option specifying the options that it
      wishes to receive from the DHCP server.  For example, if the
      client is attempting to obtain a list of DNS recursive name
      servers, it identifies the DNS Recursive Name Server option in the
      Information-request message. The server determines the appropriate
      configuration parameters for the client based on its configuration
      policies and responds with a Reply message containing the
      requested parameters.  In this example, the server would respond
      with DNS configuration parameters.

      As described in section 18.1.5 of RFC 3315, a node may include a
      Client Identifier option in the Information-request message to
      identify itself to a server, because the server administrator may
      want to customize the server's response to each node, based on the
      node's identity.

      RFC 3315 does not define any mechanisms through which the time at
      which a host uses an Information-request message to obtain updated
      configuration parameters can be controlled.  The dhc WG has
      undertaken the development of such a mechanism or mechanisms which
      will be published as Standards-track RFC(s).

      RFC 3315 also does not provide any guidance about when a host
      might use an Information-request message to obtain updated
      configuration parameters when the host has moved to a new link.
      The dhc WG is reviewing a related document, "Detection of Network
      Attachment (DNA) in IPv4" [8], which describes how a host using
      IPv4 can determine when to use DHCPv4.  Either the dhc WG or a WG
      formed from the dna BOF will undertake development of a similar
      document for IPv6.

      [8]  Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
           draft-ietf-dhc-dna-ipv4-04 (work in progress), October 2003.

=====
  5. Implementation of Stateless DHCP

      The client indicates that it is requesting
configuration
      information by sending an
Information-request message that
      includes an Option Request option
specifying the options that it
      wishes to receive from the DHCP
server.  For example, if the
      client is attempting to obtain a list of
DNS recursive name
      servers, it
identifier
identifies the DNS Recursive Name Server option in the
      Information-request message. The server determines the appropriate
      configuration parameters for the client based on its configuration
      policies and responds with a Reply message containing the
      requested parameters.  In this example, the server would respond
      with DNS configuration parameters.

   A As described in section 18.1.5 of RFC 3315, a node uses the may include a
      Client Identifier option in the Information-request message to
      identify itself to a server, because the server administrator may
      want to customize the server's response to each node, based on the
      node's identity.

   Whenever

      RFC 3315 does not define any mechanisms through which the time at
      which a client may have moved host uses an Information-request message to a new link, the obtain updated
      configuration parameters obtained for the interfaces on that link may no longer can be
   appropriate for the link to which controlled.  The dhc WG has
      undertaken the client is attached.  Examples development of times such a mechanism or mechanisms which
      will be published as Standards-track RFC(s).

      RFC 3315 also does not provide any guidance about when a client may have host
      might use an Information-request message to obtain updated
      configuration parameters when the host has moved to a new link include:

   o  The client reboots.

   o link.
      The client dhc WG is physically connected to reviewing a wired connection.

   o  The client returns from sleep mode.

   o  The client using related document, "Detection of Network
      Attachment (DNA) in IPv4" [8], which describes how a wireless technology changes access points.

   In any situation host using
      IPv4 can determine when a client may have moved to use DHCPv4.  Either the dhc WG or a new link, WG
      formed from the
   client initiates an Information-request/Reply message exchange. dna BOF will undertake development of a similar
      document for IPv6.


--=====================_5377041==_.ALT--


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


From dhcwg-admin@ietf.org  Sun Dec 21 19:36:43 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12488;
	Sun, 21 Dec 2003 19:36:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYE3G-0000aP-GW; Sun, 21 Dec 2003 19:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYE36-0000Zh-Kg
	for dhcwg@optimus.ietf.org; Sun, 21 Dec 2003 19:35:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12436
	for ; Sun, 21 Dec 2003 19:35:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYE32-0006V1-00
	for dhcwg@ietf.org; Sun, 21 Dec 2003 19:35:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYE2w-0006Uu-00
	for dhcwg@ietf.org; Sun, 21 Dec 2003 19:35:43 -0500
Received: from [203.254.224.33] (helo=mailout3.samsung.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYE2u-0006P9-00
	for dhcwg@ietf.org; Sun, 21 Dec 2003 19:35:41 -0500
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 id <0HQ900L01TAYFU@mailout3.samsung.com> for dhcwg@ietf.org; Mon,
 22 Dec 2003 09:28:10 +0900 (KST)
Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33])
 by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 with ESMTP id <0HQ9002STTAX8N@mailout3.samsung.com> for dhcwg@ietf.org; Mon,
 22 Dec 2003 09:28:10 +0900 (KST)
Received: from daniel ([168.219.203.183])
 by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23
 2003)) with ESMTPA id <0HQ900FPWTASIR@mmp2.samsung.com> for dhcwg@ietf.org;
 Mon, 22 Dec 2003 09:28:09 +0900 (KST)
Date: Mon, 22 Dec 2003 09:28:43 +0900
From: Soohong Daniel Park 
To: dhcwg@ietf.org
Message-id: <011b01c3c822$912c7900$b7cbdba8@daniel>
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/mixed; boundary="Boundary_(ID_L85RmX19F6tLo42O5nujUA)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60,
	HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no 
	version=2.60
Subject: [dhcwg] Configured Tunnel End Point Option for DHCPv6 (01)
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_L85RmX19F6tLo42O5nujUA)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_KpGnpv+ixqiTjOfRZwkvpg)"


--Boundary_(ID_KpGnpv+ixqiTjOfRZwkvpg)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT


This revised draft includes
http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-01.
txt
* allign the option diagram to appear in the single page
* text improvement
* remove samsung's IPR statement

Any comments ?


Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics 

> -----Original Message-----
> From: owner-ietf-announce@ietf.org 
> [mailto:owner-ietf-announce@ietf.org] On Behalf Of 
> Internet-Drafts@ietf.org
> Sent: Friday, December 19, 2003 5:30 AM
> To: IETF-Announce:
> Subject: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-01.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Configured Tunnel End Point Option for DHCPv6
> 	Author(s)	: S. Park
> 	Filename	: draft-daniel-dhc-dhcpv6-ctep-opt-01.txt
> 	Pages		: 6
> 	Date		: 2003-12-18
> 	
> For the newly deployed IPv6 networks to interoperate with vastly  
> deployed IPv4 networks, various transition mechanisms had been 
> proposed.  One such mechanism is configured tunnels.  This document 
> provides a mechanism by which the DHCPv6 servers can provide 
> information about the various configured tunnel end points to reach 
> the IPv6 nodes which are separated by IPv4 networks.
> 
> A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-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-daniel-dhc-dhcpv6-ctep-opt-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-daniel-dhc-dhcpv6-ctep-opt-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.  

--Boundary_(ID_KpGnpv+ixqiTjOfRZwkvpg)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7BIT






Configured Tunnel End Point Option for DHCPv6 (01)







This revised draft includes


http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-01.txt


* allign the option diagram to appear in the single page


* text improvement


* remove samsung's IPR statement




Any comments ?






Regards




Daniel (Soohong Daniel Park)


Mobile Platform Laboratory, SAMSUNG Electronics 




> -----Original Message-----


> From: owner-ietf-announce@ietf.org 


> [mailto:owner-ietf-announce@ietf.org] On Behalf Of 


> Internet-Drafts@ietf.org


> Sent: Friday, December 19, 2003 5:30 AM


> To: IETF-Announce:


> Subject: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-01.txt


> 


> 


> A New Internet-Draft is available from the on-line 


> Internet-Drafts directories.


> 


> 


>       Title           : Configured Tunnel End Point Option for DHCPv6


>       Author(s)       : S. Park


>       Filename        : draft-daniel-dhc-dhcpv6-ctep-opt-01.txt


>       Pages           : 6


>       Date            : 2003-12-18


>       


> For the newly deployed IPv6 networks to interoperate with vastly  


> deployed IPv4 networks, various transition mechanisms had been 


> proposed.  One such mechanism is configured tunnels.  This document 


> provides a mechanism by which the DHCPv6 servers can provide 


> information about the various configured tunnel end points to reach 


> the IPv6 nodes which are separated by IPv4 networks.


> 


> A URL for this Internet-Draft is: 


http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-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-daniel-dhc-dhcpv6-ctep-opt-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-daniel-dhc-dhcpv6-ctep-opt-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. <<...>>  <<...>> 





--Boundary_(ID_KpGnpv+ixqiTjOfRZwkvpg)--

--Boundary_(ID_L85RmX19F6tLo42O5nujUA)
Content-type: Message/External-body; name=ATT00094.dat
Content-transfer-encoding: 7bit
Content-disposition: attachment; filename=ATT00094.dat
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<2003-12-18142629.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-01.txt

--Boundary_(ID_L85RmX19F6tLo42O5nujUA)
Content-type: Message/External-body;
 name=draft-daniel-dhc-dhcpv6-ctep-opt-01.txt
Content-transfer-encoding: 7bit
Content-disposition: attachment;
 filename=draft-daniel-dhc-dhcpv6-ctep-opt-01.txt
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<2003-12-18142629.I-D@ietf.org>

--Boundary_(ID_L85RmX19F6tLo42O5nujUA)--

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


From dhcwg-admin@ietf.org  Mon Dec 22 03:24:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07211;
	Mon, 22 Dec 2003 03:24:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYLM9-0007lV-Uk; Mon, 22 Dec 2003 03:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYLLl-0007ku-Sc
	for dhcwg@optimus.ietf.org; Mon, 22 Dec 2003 03:23:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07198
	for ; Mon, 22 Dec 2003 03:23:35 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYLLj-0002Ah-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 03:23:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYLLi-0002Aa-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 03:23:35 -0500
Received: from mailout3.samsung.com ([203.254.224.33])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYLLi-0002A8-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 03:23:34 -0500
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 id <0HQA00L2QFAGL3@mailout3.samsung.com> for dhcwg@ietf.org; Mon,
 22 Dec 2003 17:23:04 +0900 (KST)
Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33])
 by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 with ESMTP id <0HQA00H7WF9Y3G@mailout3.samsung.com> for dhcwg@ietf.org; Mon,
 22 Dec 2003 17:22:47 +0900 (KST)
Received: from daniel ([168.219.203.183])
 by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23
 2003)) with ESMTPA id <0HQA00I6ZF9YR9@mmp2.samsung.com> for dhcwg@ietf.org;
 Mon, 22 Dec 2003 17:22:46 +0900 (KST)
Date: Mon, 22 Dec 2003 17:23:25 +0900
From: Soohong Daniel Park 
In-reply-to: 
To: "'Pekka Savola'" 
Cc: vijayak@india.hp.com, dhcwg@ietf.org
Message-id: <004b01c3c864$ded10170$b7cbdba8@daniel>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Subject: [dhcwg] RE: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-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: ,
	
Content-Transfer-Encoding: 7BIT


> Exactly.. that's why I don't have a hard stance to this at 
> the moment.  
> But if we don't know how it would be used, I have hard time believing 
> we could/should specify the DHCP mechanism in the first place :-)

Ok.

> > > Important comments:
> > > ===================
> > > 
> > > 1) the spec does not elaborate at all how the tunnel 
> > > end-point is going to configure the IP address of the node 
> > > (because the configured tunnel must be configured somehow at 
> > > the tunnel-end someone as well).  
> > > This is of course easy if coupled to DHCPv6 address 
> > > assignment and is done as part of the DHCP process at the 
> > > server, but otherwise it could be a bit trickier.
> > > 
> > > The details are probably outside the scope of this 
> specification, but 
> > > the complexity must be explicitly spelled out IMHO.
> > 
> > Well, most draft and rfc about dhcp options just address each option
> > not detail procedure. However we will consider how we can express it
> > more clear...
> 
> With the above issues, because there is no obvious "CTEP 
> protocol", it 
> might make sense to try to clarify this..

Ditto, we will consider both of them to clarify it.

> > > 3) The IPR notice is totally wrong:
> > > 
> > >   Notice Regarding Intellectual Property Rights
> > > 
> > >      See 
> > > http://www.ietf.org/ietf/IPR/samsung-general-patent04102003.txt
> > > 
> > > .. is this meant to say that Samsung has claimed some IPR 
> about this 
> > > option?  In this case, they must submit a separate IPR 
> disclaimer at 
> > > www.ietf.org/ipr, the above is not correct.  Moreover, it's 
> > > incorrect to refer to the claims directly.  Replace this 
> section with:
> > > 
> > > Intellectual Property Statement
> > > 
> > >    The IETF takes no position regarding the validity or 
> scope of any
> > >    intellectual property or other rights that might be claimed to
> > >    pertain to the implementation or use of the technology 
> described in
> > >    this document or the extent to which any license under 
> such rights
> > >    might or might not be available; neither does it 
> represent that it
> > >    has made any effort to identify any such rights. 
> Information on the
> > >    IETF's procedures with respect to rights in standards-track and
> > >    standards-related documentation can be found in 
> BCP-11. Copies of
> > >    claims of rights made available for publication and any 
> > > assurances of
> > >    licenses to be made available, or the result of an 
> attempt made to
> > >    obtain a general license or permission for the use of such
> > >    proprietary rights by implementors or users of this 
> > > specification can
> > >    be obtained from the IETF Secretariat.
> > > 
> > >    The IETF invites any interested party to bring to its 
> attention any
> > >    copyrights, patents or patent applications, or other 
> proprietary
> > >    rights which may cover technology that may be required 
> to practice
> > >    this standard. Please address the information to the 
> IETF Executive
> > >    Director.
> > > 
> > > ... and if IPR has been claimed (but not filed yet), also 
> add at the 
> > > end:
> > > 
> > >    The IETF has been notified of intellectual property rights
> > >    claimed in regard to some or all of the specification contained
> > >    in this document.  For more information consult the online list
> > >    of claimed rights.
> > 
> > replaced with 01 version. it is my habitual format.
> 
> I notice that in -01, you removed the IPR section.  I think it would 
> make sense to add the boilerplate, such as I have above, in any case 
> -- that's actually a requirement for submitting a document to the 
> IESG!

It will be added in next version with separated acknowledgement section 
by your previous comment.


Anything else ?



Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics 


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


From dhcwg-admin@ietf.org  Mon Dec 22 14:57:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03180;
	Mon, 22 Dec 2003 14:57:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYWAn-0006tq-Ek; Mon, 22 Dec 2003 14:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYWAP-0006so-Hx
	for dhcwg@optimus.ietf.org; Mon, 22 Dec 2003 14:56:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03091
	for ; Mon, 22 Dec 2003 14:56:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYWAM-0000nI-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 14:56:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYWAK-0000nB-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 14:56:34 -0500
Received: from aphrodite.gwi.net ([207.5.128.164])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYWAJ-0000n0-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 14:56:31 -0500
Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224])
	by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hBMJu557011576;
	Mon, 22 Dec 2003 14:56:14 -0500 (EST)
	(envelope-from volz@metrocast.net)
From: "Bernie Volz" 
To: "'Ralph Droms'" , 
Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-stateless-03.txt published
Date: Mon, 22 Dec 2003 14:56:09 -0500
Message-ID: <000001c3c8c5$a7e68200$6401a8c0@BVolz>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C3C89B.BF107A00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <4.3.2.7.2.20031221133312.01eaf470@flask.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60,
	HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60
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_000_0001_01C3C89B.BF107A00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ralph:

=20

OK by me.

=20

- Bernie

=20

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of =
Ralph
Droms
Sent: Sunday, December 21, 2003 1:46 PM
To: dhcwg@ietf.org
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateless-03.txt published

=20

I've submitted draft-ietf-dhc-dhcpv6-stateless-03.txt for publication.  =
This

revision includes changes in response to comments from the IESG.  The =
most=20
important changes are to section 5:

* text that describes use of Information-request/Reply message exchange =
when

  a host moves to a new link has been deleted
* text added referring to draft-ietf-dhc-dna-ipv4-04 (which addresses =
the=20
  problem of link attachment in IPv4) and to work on defining mechanism =
to=20
  control host use of Information-request/Reply message exchange (e.g.,=20
  draft-chown-dhc-stateless-dhcpv6-renumbering; note that no specific =
drafts

  are cited in draft-ietf-dhc-dhcpv6-stateless-03.txt)

I've included the revised section and an HTML diff of the -02 and -03 =
revs=20
of draft-ietf-dhc-dhcpv6-stateless.

Please respond with comments...

- Ralph

=3D=3D=3D=3D=3D

   5. Implementation of Stateless DHCP

      The client indicates that it is requesting configuration
      information by sending an Information-request message that
      includes an Option Request option specifying the options that it
      wishes to receive from the DHCP server.  For example, if the
      client is attempting to obtain a list of DNS recursive name
      servers, it identifies the DNS Recursive Name Server option in the
      Information-request message. The server determines the appropriate
      configuration parameters for the client based on its configuration
      policies and responds with a Reply message containing the
      requested parameters.  In this example, the server would respond
      with DNS configuration parameters.

      As described in section 18.1.5 of RFC 3315, a node may include a
      Client Identifier option in the Information-request message to
      identify itself to a server, because the server administrator may
      want to customize the server's response to each node, based on the
      node's identity.

      RFC 3315 does not define any mechanisms through which the time at
      which a host uses an Information-request message to obtain updated
      configuration parameters can be controlled.  The dhc WG has
      undertaken the development of such a mechanism or mechanisms which
      will be published as Standards-track RFC(s).

      RFC 3315 also does not provide any guidance about when a host
      might use an Information-request message to obtain updated
      configuration parameters when the host has moved to a new link.
      The dhc WG is reviewing a related document, "Detection of Network
      Attachment (DNA) in IPv4" [8], which describes how a host using
      IPv4 can determine when to use DHCPv4.  Either the dhc WG or a WG
      formed from the dna BOF will undertake development of a similar
      document for IPv6.

      [8]  Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
           draft-ietf-dhc-dna-ipv4-04 (work in progress), October 2003.

=3D=3D=3D=3D=3D

  5. Implementation of Stateless DHCP
=20
      The client indicates that it is requesting
configuration
      information by sending an
Information-request message that
      includes an Option Request option
specifying the options that it
      wishes to receive from the DHCP
server.  For example, if the
      client is attempting to obtain a list of
DNS recursive name
      servers, it
identifier
identifies the DNS Recursive Name Server option in the
      Information-request message. The server determines the appropriate
      configuration parameters for the client based on its configuration
      policies and responds with a Reply message containing the
      requested parameters.  In this example, the server would respond
      with DNS configuration parameters.
=20
   A As described in section 18.1.5 of RFC 3315, a node uses the may =
include
a
      Client Identifier option in the Information-request message to
      identify itself to a server, because the server administrator may
      want to customize the server's response to each node, based on the
      node's identity.
=20
   Whenever
=20
      RFC 3315 does not define any mechanisms through which the time at
      which a client may have moved host uses an Information-request =
message
to a new link, the obtain updated
      configuration parameters obtained for the interfaces on that link =
may
no longer can be
   appropriate for the link to which controlled.  The dhc WG has
      undertaken the client is attached.  Examples development of times =
such
a mechanism or mechanisms which
      will be published as Standards-track RFC(s).
=20
      RFC 3315 also does not provide any guidance about when a client =
may
have host
      might use an Information-request message to obtain updated
      configuration parameters when the host has moved to a new link
include:
=20
   o  The client reboots.
=20
   o link.
      The client dhc WG is physically connected to reviewing a wired
connection.
=20
   o  The client returns from sleep mode.
=20
   o  The client using related document, "Detection of Network
      Attachment (DNA) in IPv4" [8], which describes how a wireless
technology changes access points.
=20
   In any situation host using
      IPv4 can determine when a client may have moved to use DHCPv4.  =
Either
the dhc WG or a new link, WG
      formed from the
   client initiates an Information-request/Reply message exchange. dna =
BOF
will undertake development of a similar
      document for IPv6.
=20

------=_NextPart_000_0001_01C3C89B.BF107A00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



















Ralph:



 



OK by me.



 



- Bernie



 



-----Original =
Message-----

From: =
dhcwg-admin@ietf.org
[mailto:dhcwg-admin@ietf.org] On =
Behalf Of Ralph
Droms

Sent: Sunday, December =
21, 2003
1:46 PM

To: dhcwg@ietf.org

Subject: [dhcwg]
draft-ietf-dhc-dhcpv6-stateless-03.txt published



 



I've submitted =
draft-ietf-dhc-dhcpv6-stateless-03.txt
for publication.  This 

revision includes changes in response to comments from the IESG.  =
The most


important changes are to section 5:



* text that describes use of Information-request/Reply message exchange =
when 

  a host moves to a new link has been deleted

* text added referring to draft-ietf-dhc-dna-ipv4-04 (which addresses =
the 

  problem of link attachment in IPv4) and to work on defining =
mechanism to


  control host use of Information-request/Reply message exchange =
(e.g., 

  draft-chown-dhc-stateless-dhcpv6-renumbering; note that no =
specific
drafts 

  are cited in draft-ietf-dhc-dhcpv6-stateless-03.txt)



I've included the revised section and an HTML diff of the -02 and -03 =
revs 

of draft-ietf-dhc-dhcpv6-stateless.



Please respond with comments...



- Ralph



=3D=3D=3D=3D=3D



   5. Implementation of Stateless DHCP



      The client indicates that it is =
requesting
configuration

      information by sending an =
Information-request
message that

      includes an Option Request option =
specifying the
options that it

      wishes to receive from the DHCP =
server. 
For example, if the

      client is attempting to obtain a list of =
DNS
recursive name

      servers, it identifies the DNS Recursive =
Name
Server option in the

      Information-request message. The server
determines the appropriate

      configuration parameters for the client =
based on
its configuration

      policies and responds with a Reply =
message
containing the

      requested parameters.  In this =
example, the
server would respond

      with DNS configuration parameters.



      As described in section 18.1.5 of RFC =
3315, a
node may include a

      Client Identifier option in the
Information-request message to

      identify itself to a server, because the =
server
administrator may

      want to customize the server's response =
to each
node, based on the

      node's identity.



      RFC 3315 does not define any mechanisms =
through
which the time at

      which a host uses an Information-request =
message
to obtain updated

      configuration parameters can be
controlled.  The dhc WG has

      undertaken the development of such a =
mechanism
or mechanisms which

      will be published as Standards-track =
RFC(s).



      RFC 3315 also does not provide any =
guidance
about when a host

      might use an Information-request message =
to
obtain updated

      configuration parameters when the host =
has moved
to a new link.

      The dhc WG is reviewing a related =
document,
"Detection of Network

      Attachment (DNA) in IPv4" [8], which
describes how a host using

      IPv4 can determine when to use =
DHCPv4. 
Either the dhc WG or a WG

      formed from the dna BOF will undertake
development of a similar

      document for IPv6.



      [8]  Aboba, B., "Detection of =
Network
Attachment (DNA) in IPv4",

          
draft-ietf-dhc-dna-ipv4-04 (work in progress), October 2003.



=3D=3D=3D=3D=3D



  5. Implementation of Stateless =
DHCP
 
      The client =
indicates that it is requesting
configuration
      information by =
sending an
Information-request message =
that
      includes an =
Option Request option
specifying the options that =
it
      wishes to =
receive from the DHCP
server.  For example, if =
the
      client is =
attempting to obtain a list of
DNS recursive name
      servers, =
it
identifier
identifies the DNS =
Recursive Name Server option in the
      =
Information-request message. The server determines the =
appropriate
      configuration =
parameters for the client based on its =
configuration
      policies and =
responds with a Reply message containing the
      requested =
parameters.  In this example, the server would =
respond
      with DNS =
configuration parameters.
 
   A As described in section 18.1.5 of RFC 3315, =
a node uses the may include a
      Client =
Identifier option in the Information-request =
message to
      identify =
itself to a server, because the server administrator =
may
      want to =
customize the server's response to each node, based on =
the
      node's =
identity.
 
   Whenever
 
      RFC 3315 does not define any mechanisms through =
which the time at
      =
which a client may have =
moved host uses an =
Information-request message to a new link, the =
obtain =
updated
      configuration =
parameters obtained for the interfaces on =
that link may no longer can =
be
   appropriate for the link to which =
controlled.  The dhc WG =
has
      =
undertaken the client is attached.  =
Examples development of =
times such a mechanism or mechanisms =
which
      =
will be published as Standards-track RFC(s).
 
      =
RFC 3315 also does not provide any guidance about when a =
client may have =
host
      =
might use an Information-request message to obtain =
updated
      =
configuration parameters when the host has moved to a new =
link =
include:
 
   o  The client =
reboots.
 
   o link.
      The client dhc WG is physically connected to reviewing a wired =
connection.
 
   o  The client =
returns from sleep mode.
 
   o  The client =
using related document, =
"Detection of Network
      =
Attachment (DNA) in IPv4" [8], which describes how a =
wireless technology changes access =
points.
 
   In any =
situation host =
using
      =
IPv4 can determine when a client may have =
moved to use DHCPv4.  Either the =
dhc WG or a new link, WG
      =
formed from the
   client initiates an Information-request/Reply =
message exchange. dna BOF will undertake =
development of a similar
      =
document for IPv6.
 






------=_NextPart_000_0001_01C3C89B.BF107A00--



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


From dhcwg-admin@ietf.org  Tue Dec 23 15:34:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07860;
	Tue, 23 Dec 2003 15:34:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYtE9-0007R4-9E; Tue, 23 Dec 2003 15:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYtDx-0007Q5-Ui
	for dhcwg@optimus.ietf.org; Tue, 23 Dec 2003 15:33:49 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07614;
	Tue, 23 Dec 2003 15:33:46 -0500 (EST)
Message-Id: <200312232033.PAA07614@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, 23 Dec 2003 15:33:46 -0500
Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-stateless-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		: A Guide to Implementing Stateless DHCPv6 Service
	Author(s)	: R. Droms
	Filename	: draft-ietf-dhc-dhcpv6-stateless-03.txt
	Pages		: 10
	Date		: 2003-12-23
	
Stateless DHCPv6 service is used by nodes to obtain configuration
information such as the addresses of DNS recursive name servers
that does not require the maintenance of any dynamic state for
individual clients.  A node that uses stateless DHCP must have
obtained its IPv6 addresses through some other mechanism,
typically stateless address autoconfiguration.  This document is a
guide to the protocol messages and options that must be
implemented to provide stateless DHCPv6 service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-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-dhcpv6-stateless-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-dhcpv6-stateless-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-12-23152927.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcpv6-stateless-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-dhcpv6-stateless-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-12-23152927.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 Dec 23 22:01:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24816;
	Tue, 23 Dec 2003 22:01:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYzGg-00049n-2j; Tue, 23 Dec 2003 22:01:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYR4Y-0002f8-6Z
	for dhcwg@optimus.ietf.org; Mon, 22 Dec 2003 09:30:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17964
	for ; Mon, 22 Dec 2003 09:30:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYR4W-0004r4-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 09:30:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYR4V-0004qw-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 09:30:12 -0500
Received: from akivas.pacific.net.sg ([203.120.90.214])
	by ietf-mx with smtp (Exim 4.12)
	id 1AYR4U-0004pZ-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 09:30:10 -0500
Received: (qmail 24458 invoked from network); 22 Dec 2003 14:29:33 -0000
X-Scanned: By Symantec Anti-Virus Scan Engine
Received: from unknown (HELO maxwell2.pacific.net.sg) (203.120.90.192)
  by akivas with SMTP; 22 Dec 2003 14:29:33 -0000
Received: from pacific.net.sg ([202.156.52.246]) by maxwell2.pacific.net.sg
          with ESMTP
          id <20031222142932.KASH13917.maxwell2.pacific.net.sg@pacific.net.sg>;
          Mon, 22 Dec 2003 22:29:32 +0800
Message-ID: <3FE70050.8000604@pacific.net.sg>
Date: Mon, 22 Dec 2003 22:31:44 +0800
From: JH 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Soohong Daniel Park 
CC: dhcwg@ietf.org
Subject: Re: [dhcwg] giaddr field in DHCPREQUEST message
References: <001401c3c5ea$e20121d0$b7cbdba8@daniel>
In-Reply-To: <001401c3c5ea$e20121d0$b7cbdba8@daniel>
Content-Type: multipart/alternative;
 boundary="------------000401040400010007000802"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,
	HTML_TITLE_EMPTY autolearn=no version=2.60
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.
--------------000401040400010007000802
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Daniel,

Thank you very much for your help.

Another questions:
If DHCP server receives a DHCPREQUEST from a DHCP relay agent with 
ciaddr, giaddr set only, what should be in its DHCPACK packet?
Am I right to say that it should include:
a. ciaddr  - same as DHCPREQUEST message;
b. yiaddr - same as ciaddr -- (is it necessary? and why?)
c. giaddr - same as DHCPREQUEST message
d. request IP - same is ciaddr
e. server id - dhcp server's IP

Does DHCP client need to verify the DHCPACK from the server? If so, how?

thank you.

rgds.



Soohong Daniel Park wrote:

>>In the rfc2131 page 23, it stated that :
>>
>>If the 'giaddr' field in a DHCP message from a client is non-zero,
>>   the server sends any return messages to the 'DHCP server' 
>>port on the
>>   BOOTP relay agent whose address appears in 'giaddr'.
>>
>>It also stated the following in page 32:
>>DHCPREQUEST generated during RENEWING statev:
>>
>>      'server identifier' MUST NOT be filled in, 'requested 
>>IP address'
>>      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
>>      client's IP address. In this situation, the client is completely
>>      configured, and is trying to extend its lease. This message will
>>      be unicast, so no relay agents will be involved in its
>>      transmission.  Because 'giaddr' is therefore not filled in, the
>>      DHCP server will trust the value in 'ciaddr', and use it when
>>      replying to the client.
>>
>>Does this statement implys that the client should use unicast 
>>and send the DHCPREQUEST message directly to the DHCP server and 
>>giaddr field should be zero?
>>    
>>
>
>Yes.
>
>  
>
>>At the same page:
>> DHCPREQUEST generated during REBINDING state:
>>
>>      'server identifier' MUST NOT be filled in, 'requested 
>>IP address'
>>      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
>>      client's IP address. In this situation, the client is completely
>>      configured, and is trying to extend its lease. This message MUST
>>      be broadcast to the 0xffffffff IP broadcast address.  The DHCP
>>      server SHOULD check 'ciaddr' for correctness before replying to
>>      the DHCPREQUEST.
>>
>>If there is a relay agent between the client and server, is 
>>the relay agent supposed to 
>>send unicast to the server and giaddr is filled with relay address?
>>    
>>
>
>Yes.
>
>
>
>Regards
>
>Daniel (Soohong Daniel Park)
>Mobile Platform Laboratory, SAMSUNG Electronics 
>
>
>  
>

--------------000401040400010007000802
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Hi Daniel,



Thank you very much for your help.



Another questions:

If DHCP server receives a DHCPREQUEST from a DHCP relay agent with
ciaddr, giaddr set only, what should be in its DHCPACK packet?

Am I right to say that it should include:

a. ciaddr  - same as DHCPREQUEST message;

b. yiaddr - same as ciaddr -- (is it necessary? and why?)

c. giaddr - same as DHCPREQUEST message

d. request IP - same is ciaddr

e. server id - dhcp server's IP



Does DHCP client need to verify the DHCPACK from the server? If so, how?



thank you.



rgds.







Soohong Daniel Park wrote:



  

    
In the rfc2131 page 23, it stated that :

If the 'giaddr' field in a DHCP message from a client is non-zero,
   the server sends any return messages to the 'DHCP server' 
port on the
   BOOTP relay agent whose address appears in 'giaddr'.

It also stated the following in page 32:
DHCPREQUEST generated during RENEWING statev:

      'server identifier' MUST NOT be filled in, 'requested 
IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its
      transmission.  Because 'giaddr' is therefore not filled in, the
      DHCP server will trust the value in 'ciaddr', and use it when
      replying to the client.

Does this statement implys that the client should use unicast 
and send the DHCPREQUEST message directly to the DHCP server and 
giaddr field should be zero?
    

  

  

Yes.

  

  

    
At the same page:
 DHCPREQUEST generated during REBINDING state:

      'server identifier' MUST NOT be filled in, 'requested 
IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message MUST
      be broadcast to the 0xffffffff IP broadcast address.  The DHCP
      server SHOULD check 'ciaddr' for correctness before replying to
      the DHCPREQUEST.

If there is a relay agent between the client and server, is 
the relay agent supposed to 
send unicast to the server and giaddr is filled with relay address?
    

  

  

Yes.



Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics 


  






--------------000401040400010007000802--



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


From dhcwg-admin@ietf.org  Tue Dec 23 22:01:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24817;
	Tue, 23 Dec 2003 22:01:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYzGf-00049R-3i; Tue, 23 Dec 2003 22:01:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYLFc-0007Ws-Mx
	for dhcwg@optimus.ietf.org; Mon, 22 Dec 2003 03:17:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07053
	for ; Mon, 22 Dec 2003 03:17:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYLFa-0001yR-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 03:17:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYLFZ-0001yH-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 03:17:14 -0500
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYLFY-0001xb-00
	for dhcwg@ietf.org; Mon, 22 Dec 2003 03:17:13 -0500
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id hBM88Z531298;
	Mon, 22 Dec 2003 10:08:36 +0200
Date: Mon, 22 Dec 2003 10:08:35 +0200 (EET)
From: Pekka Savola 
To: Soohong Daniel Park 
cc: vijayak@india.hp.com, 
In-Reply-To: <00c801c3c5bf$25563d20$b7cbdba8@daniel>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [dhcwg] RE: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-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: ,
	

Inline on a couple of issues..

On Fri, 19 Dec 2003, Soohong Daniel Park wrote:
> > First, I'm not sure whether this option even makes much 
> > sense, but I'm 
> > not commenting on that at the moment.
> 
> We have tried to address why this option is required in introduction
> section.
> 
> 1. Introduction
> 
> In the initial deployment of IPv6, the IPv6 nodes may need to 
> communicate with the other IPv6 nodes via IPv4 networks.  Configured 
> tunnels [3] provide a way to encapsulate the IPv6 packets in IPv4 
> packets and tunnel them in the IPv4 network.   
>       
> This document defines a new option called Configured Tunnel End 
> Point by which the DHCPv6 [1] server can notify the client with the 
> list of end point of the configured tunnels to the various IPv6 
> networks separated by the IPv4 networks. 
> 
> Not enough ? or need text improvement ?
> Note that this draft is only proposing CTEP option not newly defined
> mechanism.

Exactly.. that's why I don't have a hard stance to this at the moment.  
But if we don't know how it would be used, I have hard time believing 
we could/should specify the DHCP mechanism in the first place :-)
 
> > Important comments:
> > ===================
> > 
> > 1) the spec does not elaborate at all how the tunnel 
> > end-point is going to configure the IP address of the node 
> > (because the configured tunnel must be configured somehow at 
> > the tunnel-end someone as well).  
> > This is of course easy if coupled to DHCPv6 address 
> > assignment and is done as part of the DHCP process at the 
> > server, but otherwise it could be a bit trickier.
> > 
> > The details are probably outside the scope of this specification, but 
> > the complexity must be explicitly spelled out IMHO.
> 
> Well, most draft and rfc about dhcp options just address each option
> not detail procedure. However we will consider how we can express it
> more clear...

With the above issues, because there is no obvious "CTEP protocol", it 
might make sense to try to clarify this..
 
> > 3) The IPR notice is totally wrong:
> > 
> >   Notice Regarding Intellectual Property Rights
> > 
> >      See 
> > http://www.ietf.org/ietf/IPR/samsung-general-patent04102003.txt
> > 
> > .. is this meant to say that Samsung has claimed some IPR about this 
> > option?  In this case, they must submit a separate IPR disclaimer at 
> > www.ietf.org/ipr, the above is not correct.  Moreover, it's 
> > incorrect to refer to the claims directly.  Replace this section with:
> > 
> > Intellectual Property Statement
> > 
> >    The IETF takes no position regarding the validity or scope of any
> >    intellectual property or other rights that might be claimed to
> >    pertain to the implementation or use of the technology described in
> >    this document or the extent to which any license under such rights
> >    might or might not be available; neither does it represent that it
> >    has made any effort to identify any such rights. Information on the
> >    IETF's procedures with respect to rights in standards-track and
> >    standards-related documentation can be found in BCP-11. Copies of
> >    claims of rights made available for publication and any 
> > assurances of
> >    licenses to be made available, or the result of an attempt made to
> >    obtain a general license or permission for the use of such
> >    proprietary rights by implementors or users of this 
> > specification can
> >    be obtained from the IETF Secretariat.
> > 
> >    The IETF invites any interested party to bring to its attention any
> >    copyrights, patents or patent applications, or other proprietary
> >    rights which may cover technology that may be required to practice
> >    this standard. Please address the information to the IETF Executive
> >    Director.
> > 
> > ... and if IPR has been claimed (but not filed yet), also add at the 
> > end:
> > 
> >    The IETF has been notified of intellectual property rights
> >    claimed in regard to some or all of the specification contained
> >    in this document.  For more information consult the online list
> >    of claimed rights.
> 
> replaced with 01 version. it is my habitual format.

I notice that in -01, you removed the IPR section.  I think it would 
make sense to add the boilerplate, such as I have above, in any case 
-- that's actually a requirement for submitting a document to the 
IESG!

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


From dhcwg-admin@ietf.org  Wed Dec 24 07:23:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06689;
	Wed, 24 Dec 2003 07:23:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ82X-0000ue-6w; Wed, 24 Dec 2003 07:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ82G-0000ty-Gf
	for dhcwg@optimus.ietf.org; Wed, 24 Dec 2003 07:22:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06682
	for ; Wed, 24 Dec 2003 07:22:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZ82F-0006PF-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 07:22:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZ80Z-0006Fg-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 07:21:00 -0500
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 1AZ7zR-00065D-00; Wed, 24 Dec 2003 07:19:49 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 24 Dec 2003 04:23:50 +0000
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 hBOCJFVM021650;
	Wed, 24 Dec 2003 04:19:15 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn1-362.cisco.com [10.82.225.106])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEW49688;
	Wed, 24 Dec 2003 07:19:13 -0500 (EST)
Message-Id: <4.3.2.7.2.20031224071615.029d6c78@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 24 Dec 2003 07:19:10 -0500
To: agenda@ietf.org
From: Ralph Droms 
Cc: Margaret.Wasserman@nokia.com, narten@us.ibm.com, dhcwg@ietf.org
In-Reply-To: <200312171812.NAA24222@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] Re: 59th IETF WG/BOF Scheduling
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 01:12 PM 12/17/2003 -0500, agenda@ietf.org wrote:
>4. You MUST provide the following information before the meeting will be 
>scheduled:
>   a. Working Group or BOF full name with acronym in brackets:

Dynamic host configuration (dhc)

>   b. AREA under which Working Group or BOF appears:

Internet

>   c. CONFLICTS you wish to avoid, please be as specific as possible:

dna, dnsext, dnsop, geopriv, ipcdn, ipv6, nemo, netconf,
v6ops, zeroconf, zerouter

>   d. Expected Attendance (figures from the 57th IETF are at the end of 
> this message):

30

>   e. Special requests (i.e. multicast):

Multicast

>   f. Number of slots:

1

>   g. Length of slot:

2 1/2 hours

>    - 1 hour
>    - 2 hours
>    - 2 1/2 hours


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


From dhcwg-admin@ietf.org  Wed Dec 24 15:45:43 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22264;
	Wed, 24 Dec 2003 15:45:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZFsN-00029y-7w; Wed, 24 Dec 2003 15:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZFrN-00029S-OU
	for dhcwg@optimus.ietf.org; Wed, 24 Dec 2003 15:44:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22241
	for ; Wed, 24 Dec 2003 15:43:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZFrM-0007Xg-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 15:44:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZFpY-0007W4-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 15:42:09 -0500
Received: from gamma.isi.edu ([128.9.144.145])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZFoU-0007Ts-00; Wed, 24 Dec 2003 15:41:02 -0500
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hBOKf1s16034;
	Wed, 24 Dec 2003 12:41:01 -0800 (PST)
Message-Id: <200312242041.hBOKf1s16034@gamma.isi.edu>
To: IETF-Announce: ;
Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 24 Dec 2003 12:41:01 -0800
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=-9.2 required=5.0 tests=AWL,MIME_BOUND_NEXTPART,
	NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60
Subject: [dhcwg] RFC 3634 on Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) 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: ,
	


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3634

        Title:      Key Distribution Center (KDC) Server Address
                    Sub-option for the Dynamic Host Configuration
                    Protocol (DHCP) CableLabs Client Configuration
                    (CCC) Option
        Author(s):  K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust
        Status:     Standards Track
        Date:       December 2003
        Mailbox:    k.luehrs@cablelabs.com,
                    richard_woundy@cable.comcast.com, john@yas.com,
                    nancy@yas.com
        Pages:      7
        Characters: 13163
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3634.txt


This document defines a new sub-option for the CableLabs Client
Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option
code for conveying the network addresses of Key Distribution Center
(KDC) servers.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <031224123935.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3634

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3634.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <031224123935.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--

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


From dhcwg-admin@ietf.org  Fri Dec 26 09:37:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22336;
	Fri, 26 Dec 2003 09:37:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZt5J-00021O-18; Fri, 26 Dec 2003 09:37:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZElf-0007lC-M1
	for dhcwg@optimus.ietf.org; Wed, 24 Dec 2003 14:34:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19624
	for ; Wed, 24 Dec 2003 14:34:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZEld-0005yD-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 14:34:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZEjp-0005wN-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 14:32:10 -0500
Received: from [205.205.236.13] (helo=sg8.global-submit.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZEie-0005u7-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 14:30:57 -0500
Received: (from root@localhost)
	by sg8.global-submit.com (8.9.3/8.9.3) id MAA07439;
	Sun, 21 Nov 2004 12:34:16 -0500
Date: Sun, 21 Nov 2004 12:34:16 -0500
Message-Id: <200411211734.MAA07439@sg8.global-submit.com>
From: request@global-submit.com
To: dhcwg@ietf.org
MIME-Version: 1.0
RMV-version: T038004R663465
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,CLICK_BELOW,
	DATE_IN_FUTURE_96_XX,EXCUSE_16,NO_REAL_NAME autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Regarding: www.firstmonday.dk/subjects/technical.html/../../../copy.html
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,

This e-mail has been sent to inform you that your 
web site URL has been submitted to our search engine
database. This is the URL that will be added.

    URL : www.firstmonday.dk/subjects/technical.html/../../../copy.html
   DATE : 11/21/2004 12:34:15
IP ADDR : Unknown IP. User had used an automated software for url submission

In order to complete this request we require that you 
click on the web site link below. This will confirm
that you do wish to be added to our search engine.

http://www.global-submit.com/confirm.cgi?T038004R663465

If you feel that you received this message in error
or you did not have your web site submitted to our
search engine, please click on the link below. We 
will make every effort to make sure that you are 
no longer bothered by this automated system. 

http://www.global-submit.com/clipout.cgi?T038004R663465

Thank you and please have a nice day

Global-Submit.com tech Staff
www.global-submit.com
1 819 571 4943






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


From dhcwg-admin@ietf.org  Fri Dec 26 10:24:51 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22338;
	Fri, 26 Dec 2003 09:37:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZt5K-00021u-BI; Fri, 26 Dec 2003 09:37:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZIAn-0007XJ-Ka
	for dhcwg@optimus.ietf.org; Wed, 24 Dec 2003 18:12:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27277
	for ; Wed, 24 Dec 2003 18:12:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZIAk-0004Lt-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 18:12:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZI8v-0004J7-00
	for dhcwg@ietf.org; Wed, 24 Dec 2003 18:10:17 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZI7z-0004G3-00; Wed, 24 Dec 2003 18:09:19 -0500
Received: from [211.227.40.245] (helo=65.246.255.50)
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1AZI7z-0004lK-Sr; Wed, 24 Dec 2003 18:09:20 -0500
Received: from  [254.109.45.230] by 65.246.255.50 with SMTP; Thu, 25 Dec 2003 15:03:17 +0100
Message-ID: 
From: "Estelle Dominguez" 
Reply-To: "Estelle Dominguez" 
To: dhcwg@ietf.org
Cc: , , ,
        
Date: Thu, 25 Dec 03 15:03:17 GMT
X-Mailer: Microsoft Outlook Express 5.00.2615.200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="3.B4E._..90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: Yes, hits=13.6 required=5.0 tests=CLICK_BELOW,
	DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_RCVD_NET_HELO,
	FROM_HAS_MIXED_NUMS,FROM_HAS_MIXED_NUMS3,MISSING_MIMEOLE,
	RCVD_NUMERIC_HELO,REMOVE_PAGE autolearn=no version=2.60
X-Spam-Report: 
	*  0.3 FROM_HAS_MIXED_NUMS From: contains numbers mixed in with letters
	*  2.0 FROM_HAS_MIXED_NUMS3 From: contains numbers mixed in with letters
	*  0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO
	*  4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting
	*  0.8 REMOVE_PAGE URI: URL of page called "remove"
	*  3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network
	*  1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE
	*  0.0 CLICK_BELOW Asks you to click below
	*  1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook
Subject: [dhcwg] RE: Invitation urttffqpqk
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: ,
	


--3.B4E._..90
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable

Hi

Your email, dhcwg@ietf.org has been submitted by a friend 
that wants to you set up on a blind date...

Click here to confirm or reschedule your date:
http://lookingforasinglewoman.com/confirm/?oc=3D50797159


Estelle Dominguez
blind-date team

 

 

 

 

 



 


take-off
http://lookingforasinglewoman.com/remove/?oc=3D50797159

n
wmyyaca   bruu m pn upio lzuxc xt rem cp dnhn
ipz
l
3tungd vctniqf bid a
 

--3.B4E._..90--


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


From dhcwg-admin@ietf.org  Mon Dec 29 08:20:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27422;
	Mon, 29 Dec 2003 08:20:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AaxJT-0001uc-2C; Mon, 29 Dec 2003 08:20:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AaxJH-0001tW-Hj
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 08:19:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27383
	for ; Mon, 29 Dec 2003 08:19:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AaxJG-00064T-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:19:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AaxHK-000623-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:17:50 -0500
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 1AaxFP-0005zi-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:15:51 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 29 Dec 2003 05:21:12 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBTDFIJ6027752
	for ; Mon, 29 Dec 2003 05:15:18 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn2-468.cisco.com [10.82.241.212])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEX51787;
	Mon, 29 Dec 2003 08:15:16 -0500 (EST)
Message-Id: <4.3.2.7.2.20031229075610.01ead5f8@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Dec 2003 08:10:51 -0500
To: dhcwg@ietf.org
From: Ralph Droms 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] New drafts as WG work items?
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 the WG meeting in Minneapolis, I mentioned six I-Ds that we need to
review for acceptance as dhc WG work items.  Here is a list of the latest
revisions of those I-Ds:

   
   
   
   
   
   

I will start an e-mail thread for comments about each of these I-Ds.  Please
respond with comments by 1/6/3004.

- Ralph


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


From dhcwg-admin@ietf.org  Mon Dec 29 08:20:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27423;
	Mon, 29 Dec 2003 08:20:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AaxJV-0001uz-Gk; Mon, 29 Dec 2003 08:20:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AaxJI-0001tb-L2
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 08:19:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27386
	for ; Mon, 29 Dec 2003 08:19:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AaxJH-00064g-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:19:51 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AaxHK-00062C-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:17:51 -0500
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 1AaxFP-0005zi-01
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:15:51 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 29 Dec 2003 05:21:14 +0000
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 hBTDFKC6001540
	for ; Mon, 29 Dec 2003 05:15:20 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn2-468.cisco.com [10.82.241.212])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEX51789;
	Mon, 29 Dec 2003 08:15:18 -0500 (EST)
Message-Id: <4.3.2.7.2.20031229080617.01e59cb8@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Dec 2003 08:12:25 -0500
To: dhcwg@ietf.org
From: Ralph Droms 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] Accept  as WG work
 item?
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: ,
	

We have a request to accept draft-vijay-dhc-dhcpv6-ipv6trans-00.txt as a WG
action item.  Here is the abstract and Introduction:

Abstract

    For the newly deployed IPv6 networks to interoperate with vastly
    deployed IPv4 networks, various transition mechanisms had been
    proposed.  One such mechanism is configured tunnels.  This document
    provides a mechanism by which the DHCPv6 servers can provide
    information about the various configured tunnel end points to reach
    the IPv6 nodes which are separated by IPv4 networks.

1.  Introduction

    In the initial deployment of IPv6, the IPv6 nodes may need to
    communicate with the other IPv6 nodes via IPv4 networks.  Configured
    tunnels [3] provide a way to encapsulate the IPv6 packets in IPv4
    packets and tunnel them in the IPv4 network.

    This document defines a new option called Configured Tunnel End Point
    by which the DHCPv6 [1] server can notify the client with the list of
    end point of the configured tunnels to the various IPv6 networks
    separated by the IPv4 networks.

    [1]  Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B.  and R.
	Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.

    [3]  R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts
         and Routers", RFC 2893,  August 2000.

Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this I-D
and whether the dhc WG should accept this I-D as a WG work item.  If there
are no objections, the default action will be for the dhc WG to accept the
I-D as a WG work item.

- Ralph


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


From dhcwg-admin@ietf.org  Mon Dec 29 08:34:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27763;
	Mon, 29 Dec 2003 08:34:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AaxWz-0002Fx-Cs; Mon, 29 Dec 2003 08:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AaxWx-0002Fl-4e
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 08:33:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27760
	for ; Mon, 29 Dec 2003 08:33:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AaxWv-0006Pw-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:33:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AaxV4-0006Ny-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:32:03 -0500
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 1AaxTt-0006Lg-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:30:49 -0500
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 hBTDUHVM016309
	for ; Mon, 29 Dec 2003 05:30:17 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn2-468.cisco.com [10.82.241.212])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEX52291;
	Mon, 29 Dec 2003 08:30:14 -0500 (EST)
Message-Id: <4.3.2.7.2.20031229081242.01ea3d30@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Dec 2003 08:18:01 -0500
To: dhcwg@ietf.org
From: Ralph Droms 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] Accept  as WG work item?
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: ,
	

We have a request to accept draft-rentschler-dhc-discovery-01.txt as a WG
action item.  Here is the Abstract and an excerpt from the Introduction:

Abstract

    The discovery mechanism described here is built upon and coexists
    with BOOTP according to RFC 1542 and DHCP according to RFC 2131
    and RFC 3203. It allows server-initiated communication to specific or all
    clients in the network, using the DHCP packet format and with that the
    relay agent functionality. The Discovery Extensons are a powerful and
    flexible add-on to client-initiated DHCP that allow a variety of
    applications.


1. Introduction

    Host Configuration using "traditional" DHCP according to RFC 2131
    is based on host- (client-) initiated communication. If a network
    is booting, all the clients start sending DHCP requests until
    accepting an answer from a DHCP server.  The server may either
    allocate IP addresses out of a pool of available adresses or,
    similar to BOOTP, pre-configured static IP addresses and
    configuration parameters for each known client.

    These concepts did not intend server-initiated and -controlled
    configuration or reconfiguration of clients. This capability was
    later partially added with RFC 3203, but the mechanism there does
    not allow to discover "silent" clients yet unknown to a server or
    trigger the configuration of such a client.  This is especially
    limiting when a server is later plugged to an already configured
    network.  These shortcomings will be overcome with the protocol
    extensions described in this document.

Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this I-D
and whether the dhc WG should accept this I-D as a WG work item.  If there
are no objections, the default action will be for the dhc WG to accept the
I-D as a WG work item.

- Ralph


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


From dhcwg-admin@ietf.org  Mon Dec 29 08:44:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28022;
	Mon, 29 Dec 2003 08:44:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaxgf-0002nI-QQ; Mon, 29 Dec 2003 08:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AaxgZ-0002mi-QE
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 08:43:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28000
	for ; Mon, 29 Dec 2003 08:43:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AaxgY-0006cm-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:43:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aaxee-0006ay-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:41:57 -0500
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 1AaxdD-0006Ye-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:40:27 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 29 Dec 2003 05:45:51 +0000
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 hBTDdvVM021138
	for ; Mon, 29 Dec 2003 05:39:57 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn2-468.cisco.com [10.82.241.212])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEX52606;
	Mon, 29 Dec 2003 08:39:55 -0500 (EST)
Message-Id: <4.3.2.7.2.20031229083744.01ea3d30@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Dec 2003 08:39:45 -0500
To: dhcwg@ietf.org
From: Ralph Droms 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] Accept  as WG work
 item?
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: ,
	

We have a request to accept draft-vijay-dhc-dhcpv6-opt-rboot-00.txt as a WG
action item.  Here is the Abstract and the Introduction:

Abstract

    This document provides new DHCPv6 (Dynamic Host Configuration
    protocol version 6) options for clients, to obtain information about
    TFTP servers and bootfiles needed for booting.

1. Introduction

    Network booting is widely used mechanism for booting up of the
    clients.  The clients contact the TFTP server to download the
    bootfiles for bootup.  The advantages of using network booting are;
    softwares will be in central server and requires maintenance at only
    one location rather than maintaining individual systems separately.
    Also, switching between different operating systems becomes easy when
    network booting is being used.  In some cases, the nodes may need
    multiple bootfiles also.  The additional boot files may be used as
    supporting software for the boot image.  Different Operating System
    vendors use different way of handling this.  Single TFTP server for
    huge number of diskless clients is prone to single point of failure.
    So, Multiple TFTP servers are needed for high availability.

    DHCPv6 (Dynamic Host Configuration Protocol Version 6) provides a
    framework for passing configuration information for hosts on an IPv6
    network.  However, DHCPv6 does not provide a way to send information
    about TFTP server address and bootfile names.  This document defines
    two options, Remote boot option and Remote Boot parameter option to
    provide information about TFTP servers and bootfile names to the
    clients.  These options are required for the clients, which are
    booting over a network.

Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this I-D
and whether the dhc WG should accept this I-D as a WG work item.  If there
are no objections, the default action will be for the dhc WG to accept the
I-D as a WG work item.

- Ralph


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


From dhcwg-admin@ietf.org  Mon Dec 29 08:44:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28026;
	Mon, 29 Dec 2003 08:44:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaxgh-0002qG-9I; Mon, 29 Dec 2003 08:44:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaxga-0002ms-Lz
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 08:43:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28006
	for ; Mon, 29 Dec 2003 08:43:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AaxgZ-0006cw-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:43:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aaxeg-0006bE-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:41:59 -0500
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 1AaxdE-0006Z2-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:40:29 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 29 Dec 2003 05:45:29 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBTDdqJ6009935
	for ; Mon, 29 Dec 2003 05:39:52 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn2-468.cisco.com [10.82.241.212])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEX52601;
	Mon, 29 Dec 2003 08:39:50 -0500 (EST)
Message-Id: <4.3.2.7.2.20031229083003.01e59cb8@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Dec 2003 08:32:41 -0500
To: dhcwg@ietf.org
From: Ralph Droms 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] Accept  as WG work
 item?
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: ,
	

We have a request to accept draft-rentschler-dhc-interface-opt-00.txt as a WG
action item.  Here is the Abstract and an excerpt from the Introduction:

Abstract

    This draft defines a new option to inform the server about
    the client's physical interface it is connected to.
    This information may be used together with the relay agent
    information option (RFC 3046) for the purpose of topology
    recognition as well as for IP and other parameter assignment
    policies.

1. Introduction

    The relay agent information option [RFC 3046], which MAY be added by
    a relay agent to a client's request to the server, MAY contain a
    Circuit ID sub option that contains the number of the physical
    interface on which the relay received this client's request.

    When the client itself is a device with multiple interfaces
    (for example a Switching Hub), it would be of interest to know which
    of the client's interfaces is connected to the relay agent or the
    server. These informations together could then easily be used to
    detect and display the active topology of the underlying network.
    To get the information about the client's physical interface to
    the server, a new option has to be introduced.

Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this I-D
and whether the dhc WG should accept this I-D as a WG work item.  If there
are no objections, the default action will be for the dhc WG to accept the
I-D as a WG work item.

- Ralph


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


From dhcwg-admin@ietf.org  Mon Dec 29 08:44:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28023;
	Mon, 29 Dec 2003 08:44:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaxgg-0002nQ-Bh; Mon, 29 Dec 2003 08:44:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaxga-0002mn-7C
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 08:43:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28003
	for ; Mon, 29 Dec 2003 08:43:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AaxgY-0006cr-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:43:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aaxef-0006b6-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:41:58 -0500
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 1AaxdD-0006Yt-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:40:27 -0500
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBTDdtJ6009971
	for ; Mon, 29 Dec 2003 05:39:55 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn2-468.cisco.com [10.82.241.212])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEX52604;
	Mon, 29 Dec 2003 08:39:53 -0500 (EST)
Message-Id: <4.3.2.7.2.20031229083514.01e59cb8@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Dec 2003 08:37:25 -0500
To: dhcwg@ietf.org
From: Ralph Droms 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] Accept  as WG work item?
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: ,
	

We have a request to accept draft-vijay-dhc-opt-extrboot-00.txt as a WG
action item.  Here is the Abstract and the Introduction:

Abstract

    Single TFTP server for huge number of diskless clients is prone
    to single point of failure.  So, Multiple TFTP servers are needed for
    high availability.  Moreover, some of the clients need multiple
    bootfiles for boot up.  This document provides a new DHCPv4 option
    for clients to obtain information about multiple TFTP servers and
    bootfiles.

1. Introduction

    DHCPv4 (Dynamic Host Configuration Protocol Version for IPv4)
    provides a framework for passing configuration information to hosts
    on an IPv4 network.  However, DHCPv4 does not provide a way to send
    more than one TFTP server address and bootfile names.  This document
    defines a new option to provide more than one TFTP server and
    bootfile names.  This option is required for clients, which are
    booting over a network and require more than one file to be
    downloaded and executed.  The multiple TFTP servers are needed for
    high availability.  Network booting is widely used mechanism for
    booting up of the clients, because of their advantages; softwares
    will be in central server and requires maintenance at only one
    location rather than maintaining individual systems separately.
    Also, switching between different operating systems becomes easy when
    network booting is being used.  The additional boot files may be used
    as supporting software for the boot image.  Different Operating
    System vendors use different way of handling this.

Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this I-D
and whether the dhc WG should accept this I-D as a WG work item.  If there
are no objections, the default action will be for the dhc WG to accept the
I-D as a WG work item.

- Ralph


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


From dhcwg-admin@ietf.org  Mon Dec 29 09:30:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28020;
	Mon, 29 Dec 2003 08:44:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaxgf-0002nA-Bf; Mon, 29 Dec 2003 08:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AaxgY-0002mX-Rb
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 08:43:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27994
	for ; Mon, 29 Dec 2003 08:43:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AaxgX-0006cY-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:43:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aaxed-0006ai-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:41:55 -0500
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 1AaxdC-0006Ye-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 08:40:26 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 29 Dec 2003 05:45:48 +0000
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 hBTDdsC6016173
	for ; Mon, 29 Dec 2003 05:39:54 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn2-468.cisco.com [10.82.241.212])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEX52603;
	Mon, 29 Dec 2003 08:39:51 -0500 (EST)
Message-Id: <4.3.2.7.2.20031229083254.01ea3d30@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Dec 2003 08:34:48 -0500
To: dhcwg@ietf.org
From: Ralph Droms 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] Accept  as WG work
 item?
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: ,
	

We have a request to accept draft-senthil-dhc-proxyserver-opt-00.txt as a WG
action item.  Here is the Abstract:

Abstract

    This document defines a new Dynamic Host Configuration Protocol
    (DHCP) option, which can be used to configure the TCP/IP host's
    Proxy Server configuration for standard protocols like HTTP, FTP,
    NNTP, SOCKS, Gopher, SLL and etc. Proxy Server provides controlled
    and efficient access to the Internet by access control mechanism
    for different types of user requests and caching frequently accessed
    information (Web pages and possibly files that might have been
    downloaded using FTP and other protocols).


Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this I-D
and whether the dhc WG should accept this I-D as a WG work item.  If there
are no objections, the default action will be for the dhc WG to accept the
I-D as a WG work item.

- Ralph


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


From dhcwg-admin@ietf.org  Mon Dec 29 17:00:53 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14309;
	Mon, 29 Dec 2003 17:00:53 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ab5Qj-0002Ar-6X; Mon, 29 Dec 2003 17:00:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ab5Q7-00029t-IL
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 16:59:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14232
	for ; Mon, 29 Dec 2003 16:59:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ab5Pv-0006wH-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 16:59:15 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ab5L4-0006ne-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 16:54:15 -0500
Received: from pan.gwi.net ([207.5.128.165])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ab5HK-0006fH-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 16:50:23 -0500
Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224])
	by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id hBTLnNGn002694;
	Mon, 29 Dec 2003 16:49:31 -0500 (EST)
	(envelope-from volz@metrocast.net)
From: "Bernie Volz" 
To: "'Ralph Droms'" , 
Subject: RE: [dhcwg] Accept  as WG work item?
Date: Mon, 29 Dec 2003 16:49:26 -0500
Message-ID: <000001c3ce55$a4514f40$6401a8c0@BVolz>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <4.3.2.7.2.20031229080617.01e59cb8@flask.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
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

Hello Ralph, et al:

I believe this draft is now
http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-01.t=
xt.
I don't have any objection in taking on this document.

- Bernie

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of =
Ralph
Droms
Sent: Monday, December 29, 2003 8:12 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Accept  as WG =
work
item?

We have a request to accept draft-vijay-dhc-dhcpv6-ipv6trans-00.txt as a =
WG
action item.  Here is the abstract and Introduction:

Abstract

    For the newly deployed IPv6 networks to interoperate with vastly
    deployed IPv4 networks, various transition mechanisms had been
    proposed.  One such mechanism is configured tunnels.  This document
    provides a mechanism by which the DHCPv6 servers can provide
    information about the various configured tunnel end points to reach
    the IPv6 nodes which are separated by IPv4 networks.

1.  Introduction

    In the initial deployment of IPv6, the IPv6 nodes may need to
    communicate with the other IPv6 nodes via IPv4 networks.  Configured
    tunnels [3] provide a way to encapsulate the IPv6 packets in IPv4
    packets and tunnel them in the IPv4 network.

    This document defines a new option called Configured Tunnel End =
Point
    by which the DHCPv6 [1] server can notify the client with the list =
of
    end point of the configured tunnels to the various IPv6 networks
    separated by the IPv4 networks.

    [1]  Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B.  and R.
	Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.

    [3]  R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts
         and Routers", RFC 2893,  August 2000.

Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this =
I-D
and whether the dhc WG should accept this I-D as a WG work item.  If =
there
are no objections, the default action will be for the dhc WG to accept =
the
I-D as a WG work item.

- 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 ajdpress@mail.com  Tue Dec 30 05:28:23 2003
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18572
	for ; Tue, 30 Dec 2003 05:28:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbH6s-0000tR-00
	for dhc-archive@ietf.org; Tue, 30 Dec 2003 05:28:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbH54-0000pA-00
	for dhc-archive@ietf.org; Tue, 30 Dec 2003 05:26:31 -0500
Received: from [61.236.238.72] (helo=ietf.org)
	by ietf-mx with smtp (Exim 4.12)
	id 1AbH3x-0000l1-00; Tue, 30 Dec 2003 05:25:23 -0500
From: "O pequeno Lucas:" 
To: dhc-archive@ietf.org
Subject: Um exemplo para o Brasil                                  ref.: mqm
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
MIME-Version: 1.0
Content-Type: text/html
Message-Id: 
Date: Tue, 30 Dec 2003 05:25:23 -0500
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: Yes, hits=9.4 required=5.0 tests=FORGED_MUA_OUTLOOK,
	FORGED_OUTLOOK_HTML,HTML_20_30,HTML_FONT_BIG,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,
	MSGID_FROM_MTA_SHORT,SUBJ_HAS_SPACES autolearn=no version=2.60
X-Spam-Report: 
	*  1.0 SUBJ_HAS_SPACES Subject contains lots of white space
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	*  0.1 HTML_FONT_BIG BODY: HTML has a big font
	*  0.5 HTML_20_30 BODY: Message is 20% to 30% HTML
	*  0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
	*  0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset
	*  1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email
	*  3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay
	*  1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only
	*  1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook










ukt Feliz Ano Novo para você e família! Atenciosamente, Ferreira Passos, Atualidade Brasileira. Lucas:EnCastellano Lucas:InEnglish ProximosEnvios:SoloEnCastellano NextMessages:OnlyInEnglish 

Dez. 29, 2003: Atualidade Brasileira, Rio de Janeiro.


O pequeno Lucas: um exemplo para o Brasil


Deu seu último suspiro segurando com suas mãozinhas um Menino Jesus e uma Medalha Milagrosa, e partiu para celebrar seu primeiro Natal no Céu


Lucas da Rocha Silva nasceu em São Paulo, no bairro industrial de Itaquera, zona leste da cidade, em 28 de novembro de 1994. Foi ele crescendo normalmente, como todas as crianças de sua idade, quando, na madrugada de 1o. de novembro de 2000, próximo a completar 6 anos, acordou com fortes dores na tíbia de sua perninha esquerda. Começava a trilhar uma dolorosa e inesperada via crucis que a Providencia, em seus misteriosos desígnios, lhe tinha reservado, e que ele aceitaria de maneira exemplar, até seu falecimento em 15 de dezembro de 2003.


Um exame de raios-x indicou uma fratura no local da dor, o que levou os médicos a engessarem sua perna por um mês. Mas a dor ia aumentando. O pequeno pegava então o seu tercinho, dizendo que rezaria Ave-Marias "até a dor passar". Conseguia assim adormecer, mas, no dia seguinte, seu drama recomeçava.


Em março de 2001, uma biopsia feita no Hospital Santa Marcelina indicou um tumor na tíbia. Passou a ser atendido no Instituto de Oncologia Pediátrica, do Hospital São Paulo, onde foi submetido pouco depois a um implante de ossos, para tentar deter o avanço do tumor; mas este se expandiu para o joelho, e depois para o fêmur, obrigando a mais duas cirurgias, a última das quais, em abril de 2003, lhe amputou a perninha esquerda.


O pequeno Lucas foi aceitando todos esses sofrimentos com admirável espírito cristão, como vindos da vontade de Deus, sem jamais se deixar abater, nem reclamar pelas dores ou pelo seu infortúnio. Disto são testemunhas seu pai, Carlos Alberto Gil da Silva, 39; sua mãe, da. Maria Aparecida da Rocha Silva, 36; seu irmão Klayton, 14; seu melhor amiguinho, Luizinho; seus familiares; médicos; professores; coleguinhas; vizinhos, e todos quantos o conheceram.


Desde a primeira cirurgia, precisou acordar três vezes por semana às 5.30 hs. da manhã, para ir ao Hospital e ser examinado pela sua médica, além de submeter-se a sessões de quimioterapia, radioterapia, e outros exames. Lá, enquanto aguardava o atendimento, costumava, com sua conversa alegre e animada, e participando de jogos, estimular outras crianças com doenças similares, que compreensivelmente se encontravam abatidas e tristes. Ainda com sua perninha amputada, ele deu um jeito de continuar a jogar bola e andar de bicicleta. Às vezes, quando o atendimento atrasava e o relógio estava perto do meio-dia, procurava sua médica e lhe dizia: "Por favor, me chama logo, tia, que preciso ir à escola". Seu senso do dever fez com que, até o final, continuasse a ir à escola, onde obteve sempre notas acima de 8.


O esforço de seus médicos, e as cirurgias, não impediram que, a partir de abril de 2003, o implacável tumor se alastrasse por seu debilitado organismo, passando do fêmur aos pulmões, e daí, ao maxilar e ao pescoço; o que foi multiplicando seus sofrimentos, pois agora sentia dificuldades para falar, se alimentar e mesmo respirar.


Em setembro de 2003, enquanto Lucas aguardava para efetuar um dos intermináveis exames e tratamentos, uma alma caridosa lhe deu de presente uma Medalha de Nossa Senhora das Graças, a Medalha Milagrosa, que passou a usar continuamente, com piedade sincera, até os últimos instantes de sua breve vida terrena, que já se aproximavam. Também ganhou um livrinho com a historia de Nossa Senhora de Fátima e dos três pastorinhos videntes, e ficou assim sabendo que um deles, Jacinta, falecera sendo ainda uma criança. Todas as noites, o pequeno Lucas pedia à sua mãe para ler algumas páginas desse livrinho; depois, rezava a Oração ao Anjo da Guarda e adormecia.


Algumas semanas antes do Natal, Lucas ganhou também um pequeno Menino Jesus na manjedoura, que recebeu com devoção e alegria, dizendo serenamente a seus pais que este Natal ele o passaria no Céu junto com seu avô paterno, que falecera alguns meses antes. De fato, seu corpo já não mais agüentava a quimioterapia e a radioterapia, que foram suspensas em novembro de 2003. Então seus pais convocaram os familiares e amigos para, na igreja de Dom Bosco, perto de seu lar, anunciar-lhes que os médicos já nada mais podiam fazer: seu filho agora estava inteiramente nas mãos de Deus e de Nossa Senhora. O menino, perto do altar, ouviu tudo com o rosto sereno, ao mesmo tempo decidido e resignado, com a mesma cristã serenidade e resignação que tivera desde o começo de sua doença, sem jamais reclamar de sua situação ou de suas enormes dores.


Na noite de 13 de dezembro, Lucas teve um agravamento de seus problemas respiratórios, devendo ser levado com urgência ao Instituto de Oncologia Pediátrica. Em sua escrivaninha, ele deixava, em perfeita ordem, "santinhos" de Maria Auxiliadora, Dom Bosco, Santa Madre Paulina, Beato Frei Galvão, Sta. Rita de Cássia, São Benedito, Santo Expedito e a Novena de Nossa Senhora das Graças, sua devoção preferida.


Só levou consigo ao Hospital, como seus mais valiosos tesouros, a Medalha Milagrosa e o pequeno Menino Jesus. Em 14 de dezembro, domingo, recebeu de mãos de seu Pároco a Unção dos Enfermos. No dia seguinte, de manhã, cada vez com maiores dificuldades para respirar, entrou em agonia. Sempre lúcido, continuava segurando com suas mãozinhas a Medalha Milagrosa e o Menino Jesus. Percebendo que as forças o abandonavam, conseguiu sussurrar com dificuldade: "Mãe, me ajude a segurar o Menino Jesus..." Pouco depois, dava seu último suspiro. 


O Menino Jesus, sem dúvida, retribuiu o afeto dessa alma inocente, levando-o consigo para passar o primeiro Natal no Céu. 


Para Deus não existem heróis anônimos; mais ainda, Ele muitas vezes nos dá a possibilidade de conhecer essas vidas, para nossa edificação, e para nos ajudar, com seus exemplos, a enfrentar as enormes dificuldades do dia-a-dia. O pequeno Lucas foi um herói, apesar de ter só 9 anos: por sua fé, e pela inteira aceitação do misterioso e luminoso caminho da dor que a Providencia lhe preparou, trilhando os passos do Divino Mestre. O pequeno Lucas é, neste sentido, um grande exemplo para o Brasil. 


Gonçalo Guimarães, autor deste artigo, é jornalista.


LINKS:


Para enviar uma mensagem aos pais e irmão do pequeno Lucas, clique em:


FamiliaDoLucas:MinhaMensagem


Para enviar ao autor do artigo sua valiosa opinião, clique aqui: ArtigoSobreLucas:MinhaOpiniao


Para receber gratuitamente, por e-mail, duas fotos de Lucas (uma com 6 anos, e outra, com 9, poucos dias antes de falecer), clique aqui:


DesejoReceberFotosDeLucas


Para ser retirado de nosso Address Book, clique em:


RetirarDoAddresBook


Nota: este artigo pode ser reproduzido parcial ou totalmente, de preferência, citando a fonte: Atualidade Brasileira.






From dhcwg-admin@ietf.org  Tue Dec 30 10:47:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26620;
	Tue, 30 Dec 2003 10:47:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbM5F-0001AJ-BH; Tue, 30 Dec 2003 10:47:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbKys-0007lw-W0
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 09:36:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23862
	for ; Tue, 30 Dec 2003 09:36:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbKyr-0000tH-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 09:36:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbKwy-0000pz-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 09:34:25 -0500
Received: from amrita.pacific.net.sg ([203.120.90.219])
	by ietf-mx with smtp (Exim 4.12)
	id 1AbKvr-0000mM-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 09:33:15 -0500
Received: (qmail 7522 invoked from network); 30 Dec 2003 14:32:41 -0000
X-Scanned: By Symantec Anti-Virus Scan Engine
Received: from unknown (HELO maxwell6.pacific.net.sg) (203.120.90.212)
  by amrita with SMTP; 30 Dec 2003 14:32:41 -0000
Received: from pacific.net.sg ([202.156.48.236]) by maxwell6.pacific.net.sg
          with ESMTP
          id <20031230143240.GSHF1209.maxwell6.pacific.net.sg@pacific.net.sg>
          for ; Tue, 30 Dec 2003 22:32:40 +0800
Message-ID: <3FF18D18.2070909@pacific.net.sg>
Date: Tue, 30 Dec 2003 22:35:04 +0800
From: JH 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
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
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,TO_ADDRESS_EQ_REAL 
	autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] "hops" in DHCP messages
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,

What is the purpose of this field in DHCP messages?

Is DHCP relay agent supposed to increased it by one when it pass a DHCP 
message to the DHCP server?
How about the message from DHCP server to the relay agent?

What a DHCP server supposed to do if the hops is zero from DHCP relay?

thank you.



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


From dhcwg-admin@ietf.org  Tue Dec 30 10:47:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26619;
	Tue, 30 Dec 2003 10:47:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbM5E-0001AB-UK; Tue, 30 Dec 2003 10:47:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ab7cv-00076x-4L
	for dhcwg@optimus.ietf.org; Mon, 29 Dec 2003 19:20:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19841
	for ; Mon, 29 Dec 2003 19:20:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ab7ct-0004mL-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 19:20:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ab7au-0004bF-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 19:18:44 -0500
Received: from natsmtp01.rzone.de ([81.169.145.166])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ab7Z4-0004SW-00
	for dhcwg@ietf.org; Mon, 29 Dec 2003 19:16:50 -0500
Received: from sip ([218.106.195.249])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hBU0FRtQ009188;
	Tue, 30 Dec 2003 01:15:47 +0100 (MET)
From: "Christian Stredicke" 
To: 
Cc: "'Henry Sinnreich'" ,
        "'Henning Schulzrinne'" ,
        "'Wilhelm Wimmreuter'" ,
        "'Rentschler, Markus'" 
Subject: AW: [dhcwg] Comments on draft-rentschler-dhc-discovery-00.txt
Date: Tue, 30 Dec 2003 08:14:32 +0800
Message-ID: <01c901c3ce69$f3be0370$0af294db@sip>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <01C3CE33.BADE7160.mrentsch@arcor.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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

I do think it's helpful (especially for my primary interest, SIP endpoints
which are located in private networks) and I would be happy if the dhc WG
would accept this I-D as a WG work item!
--
Christian Stredicke
tel:+49.30.39833.401 (ENUM & PSTN)


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


From dhcwg-admin@ietf.org  Tue Dec 30 13:17:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02068;
	Tue, 30 Dec 2003 13:17:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbOQQ-0007zr-8h; Tue, 30 Dec 2003 13:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbOPw-0007yc-Ml
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 13:16:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02051
	for ; Tue, 30 Dec 2003 13:16:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbOPu-0001Bi-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 13:16:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbOO9-00018w-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 13:14:41 -0500
Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbONG-00014a-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 13:13:46 -0500
Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 id <0HQP00701Z6FQ8@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 13:13:11 -0500 (EST)
Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87])
 by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPA id <0HQP00298ZXXJS@endeavor.poss.com>; Tue,
 30 Dec 2003 13:13:10 -0500 (EST)
Date: Tue, 30 Dec 2003 13:12:50 -0500
From: "Kevin A. Noll" 
Subject: RE: [dhcwg] "hops" in DHCP messages
In-reply-to: <3FF18D18.2070909@pacific.net.sg>
To: JH , dhcwg@ietf.org
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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


DHCP (RFC 2131) depends on BOOTP relay agent functionality. You can find
the specifics in RFC 951 and RFC 1542.

The hops field counts the number of times relay agents have relayed the 
BOOTP/DHCP message. If hops exceeds 16, then the relay agent is required 
to drop the message, i.e. not continue relaying it. This prevents an 
infinite forwarding loop.

The DHCP server is not required to do anything with the hops field.

--kan--

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of JH
> Sent: Tuesday, 30 December, 2003 9:35 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] "hops" in DHCP messages
> 
> 
> Hi,
> 
> What is the purpose of this field in DHCP messages?
> 
> Is DHCP relay agent supposed to increased it by one when it pass a DHCP 
> message to the DHCP server?
> How about the message from DHCP server to the relay agent?
> 
> What a DHCP server supposed to do if the hops is zero from DHCP relay?
> 
> thank you.
> 
> 
> 
> _______________________________________________
> 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  Tue Dec 30 15:19:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07043;
	Tue, 30 Dec 2003 15:19:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQKT-0003En-Ft; Tue, 30 Dec 2003 15:19:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQK0-0003DQ-Cb
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 15:18:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07002
	for ; Tue, 30 Dec 2003 15:18:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQJz-0006BV-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:18:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbQI0-000661-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:16:29 -0500
Received: from toccata.fugue.com ([204.152.186.142])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQFz-00061B-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:14:23 -0500
Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232])
	by toccata.fugue.com (Postfix) with ESMTP
	id 29D9D1B209C; Tue, 30 Dec 2003 14:10:25 -0600 (CST)
In-Reply-To: <4.3.2.7.2.20031229080617.01e59cb8@flask.cisco.com>
References: <4.3.2.7.2.20031229080617.01e59cb8@flask.cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
From: Ted Lemon 
Subject: Re: [dhcwg] Accept  as WG work item?
Date: Tue, 30 Dec 2003 14:14:20 -0600
To: Ralph Droms 
X-Mailer: Apple Mail (2.609)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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

I think this one is fine in principle.


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


From dhcwg-admin@ietf.org  Tue Dec 30 15:25:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07277;
	Tue, 30 Dec 2003 15:25:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQQH-0003Qe-W5; Tue, 30 Dec 2003 15:25:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQPr-0003Pp-0g
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 15:24:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07264
	for ; Tue, 30 Dec 2003 15:24:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQPo-0006T9-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:24:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbQO5-0006QQ-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:22:46 -0500
Received: from toccata.fugue.com ([204.152.186.142])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQMv-0006LX-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:21:33 -0500
Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232])
	by toccata.fugue.com (Postfix) with ESMTP
	id C62FC1B2001; Tue, 30 Dec 2003 14:17:35 -0600 (CST)
In-Reply-To: <4.3.2.7.2.20031229081242.01ea3d30@flask.cisco.com>
References: <4.3.2.7.2.20031229081242.01ea3d30@flask.cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
From: Ted Lemon 
Subject: Re: [dhcwg] Accept  as WG work item?
Date: Tue, 30 Dec 2003 14:21:31 -0600
To: Ralph Droms 
X-Mailer: Apple Mail (2.609)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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

I don't see any point in working on this.   Based on the insistence of 
a few folks that we really needed DHCP Reconfigure, we published an RFC 
describing how to do it, which as far as I know has seen zero adoption 
thus far.   This proposal has many of the disadvantages of DHCP 
Reconfigure, isn't really functionally related to DHCP anyway, and 
doesn't look like it would work.   I see no point in spending WG time 
working on this - I think the authors need to go off and do some 
research (that is, come up with a working prototype and adjust the 
draft accordingly) and then come back to us or to some appropriate WG 
when their ideas are a little better baked.


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


From dhcwg-admin@ietf.org  Tue Dec 30 15:31:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07482;
	Tue, 30 Dec 2003 15:31:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQW6-0003cI-PM; Tue, 30 Dec 2003 15:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQVb-0003b2-SF
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 15:30:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07472
	for ; Tue, 30 Dec 2003 15:30:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQVa-0006eZ-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:30:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbQTk-0006bY-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:28:37 -0500
Received: from toccata.fugue.com ([204.152.186.142])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQTO-0006YY-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:28:15 -0500
Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232])
	by toccata.fugue.com (Postfix) with ESMTP
	id D59CB1B209F; Tue, 30 Dec 2003 14:24:17 -0600 (CST)
In-Reply-To: <4.3.2.7.2.20031229083003.01e59cb8@flask.cisco.com>
References: <4.3.2.7.2.20031229083003.01e59cb8@flask.cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
From: Ted Lemon 
Subject: Re: [dhcwg] Accept  as WG work item?
Date: Tue, 30 Dec 2003 14:28:13 -0600
To: Ralph Droms 
X-Mailer: Apple Mail (2.609)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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

This draft is half-baked.   There is no discussion about how the option 
would actually be used, sufficient for the reader to figure out what to 
do with it.   It's not at all clear to me that the authors have thought 
through how it will be used, or that they have a solid understanding of 
how the DHCP protocol works in practice.   I am afraid that the option 
proposed in this draft actually can't be used in the way they think it 
can.   I'm not against having an option like this in principle, but 
based on what's been said in the draft, I don't see any point in making 
the draft a WG item - the draft simply doesn't make sense as written.

I would really encourage the authors to come to Seoul and spend some 
time talking to DHCWG members in person, to see if what they need 
actually makes sense, and to talk about how to make it happen.   I may 
be mistaken about the authors' level of experience with DHCP, but 
that's what comes across in the written document, and that's what we 
have to work with.   I think that any discussions at this point should 
be informal, and should happen outside of the actual working group 
session (perhaps before the session).   The reason for talking in 
person rather than over the internet is that often misunderstandings 
that can take weeks or months to resolve over email can be cleared up 
very quickly when the participants are able to interact face-to-face.

The bottom line is that as of now, I request that this draft not be 
adopted as a WG work item.


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


From dhcwg-admin@ietf.org  Tue Dec 30 15:37:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08042;
	Tue, 30 Dec 2003 15:37:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQbt-0003tS-N1; Tue, 30 Dec 2003 15:37:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQbQ-0003sj-Ai
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 15:36:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07988
	for ; Tue, 30 Dec 2003 15:36:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQbO-000725-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:36:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbQZo-0006y8-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:34:53 -0500
Received: from toccata.fugue.com ([204.152.186.142])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQY7-0006qk-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 15:33:07 -0500
Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232])
	by toccata.fugue.com (Postfix) with ESMTP
	id 5086A1B209F; Tue, 30 Dec 2003 14:29:10 -0600 (CST)
In-Reply-To: <4.3.2.7.2.20031229083744.01ea3d30@flask.cisco.com>
References: <4.3.2.7.2.20031229083744.01ea3d30@flask.cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5FB9C9D2-3B07-11D8-BC40-000A95D9C74C@fugue.com>
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
From: Ted Lemon 
Subject: Re: [dhcwg] Accept  as WG work item?
Date: Tue, 30 Dec 2003 14:33:06 -0600
To: Ralph Droms 
X-Mailer: Apple Mail (2.609)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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

I think this draft is useful, and should be adopted as a work item.   
One comment on the draft as it stands - I don't see any reason for 
encapsulation.   Is there some reason why we should do this as an 
encapsulation?


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


From dhcwg-admin@ietf.org  Tue Dec 30 16:07:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08856;
	Tue, 30 Dec 2003 16:07:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbR4v-00055G-KU; Tue, 30 Dec 2003 16:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbR4R-00054P-63
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 16:06:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08852
	for ; Tue, 30 Dec 2003 16:06:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbR4M-0000AQ-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 16:06:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbR2T-00008p-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 16:04:29 -0500
Received: from aphrodite.gwi.net ([207.5.128.164])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbR1M-00006i-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 16:03:20 -0500
Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224])
	by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hBUL3857097987;
	Tue, 30 Dec 2003 16:03:16 -0500 (EST)
	(envelope-from volz@metrocast.net)
From: "Bernie Volz" 
To: "'Ted Lemon'" , "'Ralph Droms'" 
Cc: 
Subject: RE: [dhcwg] Accept  as WG work item?
Date: Tue, 30 Dec 2003 16:03:12 -0500
Message-ID: <000101c3cf18$593b2940$6401a8c0@BVolz>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: 
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
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

I fully agree with Ted's objections to this. And, this proposal has major
security issues (after all it would have been easy to allow
multicast/broadcast reconfigures in DHCPv6/DHCPv4 except for the security
issues that this would open).

- Bernie

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted
Lemon
Sent: Tuesday, December 30, 2003 3:22 PM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Accept  as WG
work item?

I don't see any point in working on this.   Based on the insistence of 
a few folks that we really needed DHCP Reconfigure, we published an RFC 
describing how to do it, which as far as I know has seen zero adoption 
thus far.   This proposal has many of the disadvantages of DHCP 
Reconfigure, isn't really functionally related to DHCP anyway, and 
doesn't look like it would work.   I see no point in spending WG time 
working on this - I think the authors need to go off and do some 
research (that is, come up with a working prototype and adjust the 
draft accordingly) and then come back to us or to some appropriate WG 
when their ideas are a little better baked.


_______________________________________________
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  Tue Dec 30 22:17:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25610;
	Tue, 30 Dec 2003 22:17:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbWqz-0001DN-2L; Tue, 30 Dec 2003 22:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbWqZ-0001Co-Ni
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 22:16:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25602
	for ; Tue, 30 Dec 2003 22:16:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbWqW-0005g3-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:16:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbWoh-0005eo-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:14:39 -0500
Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbWo3-0005c5-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:13:59 -0500
Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 id <0HQQ00K01OY8QZ@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 22:13:30 -0500 (EST)
Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87])
 by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPA id <0HQQ0024HOYGXJ@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 22:13:30 -0500 (EST)
Date: Tue, 30 Dec 2003 22:13:07 -0500
From: "Kevin A. Noll" 
In-reply-to: <000101c3cf18$593b2940$6401a8c0@BVolz>
To: dhcwg@ietf.org
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7BIT
Subject: [dhcwg] Valid states for use of DHCPRELEASE?
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


Can someone verify for me that RFC 2131 doesn't explicitly limit
when a client may send a DHCPRELEASE.

It doesn't make any sense for the client to send a DHCPRELEASE 
unless it is in BOUND, RENEWING, or REBINDING.

In addition, by the nature of a DHCPRELEASE, the client would 
have to go back to the INIT state when it sends a RELEASE.

I'm just looking for someone to verify that my interpretation is 
correct.

Thanks.

--kan--
--
Kevin A. Noll, KD4WOZ
CCIE 10948, CCDP
Perfect Order, Inc.		
Kevin.Noll@perfectorder.com
717-796-1936


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


From dhcwg-admin@ietf.org  Tue Dec 30 22:39:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26382;
	Tue, 30 Dec 2003 22:39:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbXCH-000204-Kx; Tue, 30 Dec 2003 22:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbXBt-0001zV-TR
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 22:38:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26376
	for ; Tue, 30 Dec 2003 22:38:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbXBq-0006Mr-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:38:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbXA0-0006L8-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:36:41 -0500
Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbX9f-0006IS-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:36:19 -0500
Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 id <0HQQ00K01OY8QZ@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 22:35:50 -0500 (EST)
Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87])
 by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPA id <0HQQ00270PZOXJ@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 22:35:49 -0500 (EST)
Date: Tue, 30 Dec 2003 22:35:27 -0500
From: "Kevin A. Noll" 
Subject: RE: [dhcwg] Accept  as WG work
 item?
In-reply-to: <000101c3cf18$593b2940$6401a8c0@BVolz>
To: dhcwg@ietf.org
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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



I agree with Ted and Bernie. 

The suggested implementation in this draft leaves too much trust with 
the client. Not to mention some potential interoperability problems.

In addition, there are other methods available to perform functions 
that are being proposed.

--kan--

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
> Bernie Volz
> Sent: Tuesday, 30 December, 2003 4:03 PM
> To: 'Ted Lemon'; 'Ralph Droms'
> Cc: dhcwg@ietf.org
> Subject: RE: [dhcwg] Accept  as
> WG work item?
> 
> 
> I fully agree with Ted's objections to this. And, this proposal has major
> security issues (after all it would have been easy to allow
> multicast/broadcast reconfigures in DHCPv6/DHCPv4 except for the security
> issues that this would open).
> 
> - Bernie
> 
> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted
> Lemon
> Sent: Tuesday, December 30, 2003 3:22 PM
> To: Ralph Droms
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] Accept  as WG
> work item?
> 
> I don't see any point in working on this.   Based on the insistence of 
> a few folks that we really needed DHCP Reconfigure, we published an RFC 
> describing how to do it, which as far as I know has seen zero adoption 
> thus far.   This proposal has many of the disadvantages of DHCP 
> Reconfigure, isn't really functionally related to DHCP anyway, and 
> doesn't look like it would work.   I see no point in spending WG time 
> working on this - I think the authors need to go off and do some 
> research (that is, come up with a working prototype and adjust the 
> draft accordingly) and then come back to us or to some appropriate WG 
> when their ideas are a little better baked.
> 
> 
> _______________________________________________
> 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  Tue Dec 30 22:47:29 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26589;
	Tue, 30 Dec 2003 22:47:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbXK1-0002DL-CZ; Tue, 30 Dec 2003 22:47:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbXJZ-0002CP-Cm
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 22:46:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26578
	for ; Tue, 30 Dec 2003 22:46:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbXJV-0006Xd-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:46:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbXHe-0006W4-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:44:35 -0500
Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbXFv-0006RG-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:42:47 -0500
Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 id <0HQQ00K01OY8QZ@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 22:42:18 -0500 (EST)
Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87])
 by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPA id <0HQQ0027XQAFXJ@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 22:42:17 -0500 (EST)
Date: Tue, 30 Dec 2003 22:41:54 -0500
From: "Kevin A. Noll" 
Subject: RE: [dhcwg] Accept  as WG
 work item?
In-reply-to: <4.3.2.7.2.20031229083003.01e59cb8@flask.cisco.com>
To: dhcwg@ietf.org
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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



I don't think this is worth considering. I'm not even sure what
the purpose of the proposed option is. It sounds suspiciously
similar to the Client Identifier, but I can't quite tell.

--kan--

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
> Ralph Droms
> Sent: Monday, 29 December, 2003 8:33 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Accept  as
> WG work item?
>
>
> We have a request to accept
> draft-rentschler-dhc-interface-opt-00.txt as a WG
> action item.  Here is the Abstract and an excerpt from the Introduction:
>
> Abstract
>
>     This draft defines a new option to inform the server about
>     the client's physical interface it is connected to.
>     This information may be used together with the relay agent
>     information option (RFC 3046) for the purpose of topology
>     recognition as well as for IP and other parameter assignment
>     policies.
>
> 1. Introduction
>
>     The relay agent information option [RFC 3046], which MAY be added by
>     a relay agent to a client's request to the server, MAY contain a
>     Circuit ID sub option that contains the number of the physical
>     interface on which the relay received this client's request.
>
>     When the client itself is a device with multiple interfaces
>     (for example a Switching Hub), it would be of interest to know which
>     of the client's interfaces is connected to the relay agent or the
>     server. These informations together could then easily be used to
>     detect and display the active topology of the underlying network.
>     To get the information about the client's physical interface to
>     the server, a new option has to be introduced.
>
> Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this I-D
> and whether the dhc WG should accept this I-D as a WG work item.  If there
> are no objections, the default action will be for the dhc WG to accept the
> I-D as a WG work item.
>
> - 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  Tue Dec 30 22:51:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26737;
	Tue, 30 Dec 2003 22:51:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbXNt-0002RZ-62; Tue, 30 Dec 2003 22:51:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbXNZ-0002RF-Lv
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 22:50:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26711
	for ; Tue, 30 Dec 2003 22:50:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbXNW-0006fl-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:50:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbXLh-0006dI-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:48:46 -0500
Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbXLA-0006Zu-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 22:48:12 -0500
Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 id <0HQQ00M01QDAC7@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 22:47:43 -0500 (EST)
Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87])
 by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPA id <0HQQ0028GQJHXJ@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 22:47:42 -0500 (EST)
Date: Tue, 30 Dec 2003 22:47:20 -0500
From: "Kevin A. Noll" 
Subject: RE: [dhcwg] Accept  as WG work item?
In-reply-to: <4.3.2.7.2.20031229083254.01ea3d30@flask.cisco.com>
To: dhcwg@ietf.org
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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



I think these drafts are worth consideration...
 
draft-senthil-dhc-proxyserver-opt

draft-vijay-dhc-opt-extrboot

draft-vijay-dhc-dhcpv6-ipv6trans

draft-vijay-dhc-dhcpv6-opt-rboot



--kan--


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


From dhcwg-admin@ietf.org  Tue Dec 30 23:27:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27509;
	Tue, 30 Dec 2003 23:27:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbXwj-0003HA-02; Tue, 30 Dec 2003 23:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbXwX-0003Gs-Vv
	for dhcwg@optimus.ietf.org; Tue, 30 Dec 2003 23:26:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27500
	for ; Tue, 30 Dec 2003 23:26:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbXwW-0007bA-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 23:26:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbXua-0007YR-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 23:24:48 -0500
Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbXu8-0007UT-00
	for dhcwg@ietf.org; Tue, 30 Dec 2003 23:24:20 -0500
Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 id <0HQQ00N01R2C2Q@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 23:23:51 -0500 (EST)
Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87])
 by endeavor.poss.com
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPA id <0HQQ002BIS7PXJ@endeavor.poss.com> for dhcwg@ietf.org; Tue,
 30 Dec 2003 23:23:50 -0500 (EST)
Date: Tue, 30 Dec 2003 23:23:28 -0500
From: "Kevin A. Noll" 
Subject: RE: [dhcwg] Valid states for use of DHCPRELEASE?
In-reply-to: 
To: dhcwg@ietf.org
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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


Could I also claim that an additional state could be
added to the client state machine (call it "STOPPED") that
the client transitions to after sending a DHCPRELEASE?

The assumption would be that the STOPPED state would be
associated with a graceful shutdown of the system or with
some external process that caused the client to RELEASE. If
this is the case, then STOPPED would be a final state (like
INIT or INIT-REBOOT are the beginning states).

--kan--

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
> Kevin A. Noll
> Sent: Tuesday, 30 December, 2003 10:13 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Valid states for use of DHCPRELEASE?
> 
> 
> 
> Can someone verify for me that RFC 2131 doesn't explicitly limit
> when a client may send a DHCPRELEASE.
> 
> It doesn't make any sense for the client to send a DHCPRELEASE 
> unless it is in BOUND, RENEWING, or REBINDING.
> 
> In addition, by the nature of a DHCPRELEASE, the client would 
> have to go back to the INIT state when it sends a RELEASE.
> 
> I'm just looking for someone to verify that my interpretation is 
> correct.
> 
> Thanks.
> 
> --kan--
> --
> Kevin A. Noll, KD4WOZ
> CCIE 10948, CCDP
> Perfect Order, Inc.		
> Kevin.Noll@perfectorder.com
> 717-796-1936
> 
> 
> _______________________________________________
> 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