From mailman-admin@ietf.org Sun Feb 1 09:16:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14100 for ; Sun, 1 Feb 2004 09:16: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 1AnINw-0000Gn-1D for DHC-ARCHIVE@lists.ietf.org; Sun, 01 Feb 2004 09:15:40 -0500 Date: Sun, 01 Feb 2004 09:15:40 -0500 Message-ID: <20040201141540.1364.3607.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Mon Feb 2 13:40:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29907; Mon, 2 Feb 2004 13:40:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnizL-000295-Uc; Mon, 02 Feb 2004 13:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aniyh-00026b-72 for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 13:39: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 NAA29844 for ; Mon, 2 Feb 2004 13:39:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aniyf-0007iN-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 13:39:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anix4-0007OK-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 13:37:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Aniw1-00072p-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 13:36:37 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2004 10:36:50 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i12IZv3I015000 for ; Mon, 2 Feb 2004 10:36:06 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFT03401; Mon, 2 Feb 2004 13:35:56 -0500 (EST) Message-Id: <4.3.2.7.2.20040202133508.01f8e730@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Feb 2004 13:35:54 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Tentative schedule for WG meeting in Seoul 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 dhc WG meeting in Seoul has been tentatively scheduled as follows: TUESDAY, March 2, 2004 0900-1130 Morning Sessions APP crisp Cross Registry Information Service Protocol WG INT dhc Dynamic Host Configuration WG OPS psamp Packet Sampling WG RTG forces Forwarding and Control Element Separation WG TSV avt Audio/Video Transport WG - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 2 15:13:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06427; Mon, 2 Feb 2004 15:13: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 1AnkRH-0000tt-WA; Mon, 02 Feb 2004 15:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkR7-0000pu-8b for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 15:12: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 PAA06328 for ; Mon, 2 Feb 2004 15:12:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkR6-0003y3-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 15:12:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkQA-0003tR-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 15:11:50 -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 1AnkPI-0003ju-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 15:10:56 -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 i12KANjc014287; Mon, 2 Feb 2004 12:10:23 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFT13676; Mon, 2 Feb 2004 15:10:21 -0500 (EST) Message-Id: <4.3.2.7.2.20040202151006.0201f080@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Feb 2004 15:10:13 -0500 To: Naiming Shen From: Ralph Droms Subject: Re: [dhcwg] Agenda items for IETF-59, Seoul Cc: dhcwg@ietf.org, kishore@redback.com, souissal@redback.com, tom_soon@labs.sbc.com, phantom@kt.co.kr In-Reply-To: <200401300433.UAA15597@redback.com> References: <4.3.2.7.2.20040129193209.02b91dc0@flask.cisco.com> 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.0 required=5.0 tests=AWL 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: , Done... - Ralph At 08:33 PM 1/29/2004 -0800, Naiming Shen wrote: >Ralph, > >can I have 5 minutes on draft draft-shen-dhc-block-alloc-02.txt >(the only diff from -01.txt to -02.txt is an author name typo fix) >just submitted. thanks. > > ]The dhc WG will meet during IETF59 in Seoul. Included below is a > ]preliminary, draft agenda for the WG meeting. Please respond with requests > ]for additional agenda items or other comments directly to the WG chair, > ]rdroms@cisco.com, and the dhcwg@ietf.org mailing list. > ] > ]- Ralph > ] > ] > ] DHC WG agenda - IETF 59 > ] > ] (Last revised 01/29/2004 03:45 PM) > ] ---------------------------------- > ] > ]Administrivia Ralph Droms 05 > minute >s > ] Agenda bashing > ] > ]DHCP Option for Proxy Server Configuration 05 > minute >s > ] > ] > ]The Extended Remote Boot Option for DHCPv4 05 > minute >s > ] > ] > ]DHCPv6 Support for Remote Boot 05 > minute >s > ] > ] > ]Configured Tunnel End Point Option for DHCPv6 05 > minute >s > ] > ] > ]Requirements for Proposed Changes to the Dynamic Host Configuration > ]Protocol for IPv4 (DHCPv4) 05 minutes > ] > ] > ]Node-Specific Client Identifiers for DHCPv4 05 > minute >s > ] > ] > ]Rapid Commit Option for DHCPv4 05 > minute >s > ] > ] > ]Update on IPR issue with two drafts Ralph Droms 15 > minute >s > ] > ]Update of dhc WG charter Ralph Droms 15 > minute >s > ] > --------- >-- > ]Total 70 > minute >s > ] > ] > ]_______________________________________________ > ]dhcwg mailing list > ]dhcwg@ietf.org > ]https://www1.ietf.org/mailman/listinfo/dhcwg > >- Naiming > >_______________________________________________ >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 Mon Feb 2 15:32:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07572; Mon, 2 Feb 2004 15:32: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 1Ankjg-0004Ad-8M; Mon, 02 Feb 2004 15:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkjU-0004A6-Fo for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 15:31: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 PAA07543 for ; Mon, 2 Feb 2004 15:31:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkjT-0005is-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 15:31:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkiX-0005eH-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 15:30:50 -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 1Ankhk-0005V5-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 15:30:00 -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 i12KTQjc013215 for ; Mon, 2 Feb 2004 12:29:27 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFT15580; Mon, 2 Feb 2004 15:29:25 -0500 (EST) Message-Id: <4.3.2.7.2.20040202152832.01fcead0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Feb 2004 15:29:22 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Revised agenda 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: , DHC WG agenda - IETF 59 0900 Tue 03/04/2004 (tentative) (Last revised 02/02/2004 03:24 PM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing DHCP Option for Proxy Server Configuration 05 minutes The Extended Remote Boot Option for DHCPv4 05 minutes DHCPv6 Support for Remote Boot 05 minutes Configured Tunnel End Point Option for DHCPv6 05 minutes Requirements for Proposed Changes to DHCPv4 05 minutes Node-Specific Client Identifiers for DHCPv4 05 minutes Rapid Commit Option for DHCPv4 05 minutes Micro-block IP Address Allocation With DHCP Proxy Server Naiming Shen 05 minutes Renumbering Requirements for Stateless DHCPv6 Stig Venaas 10 minutes Lifetime Option for DHCPv6 Stig Venaas 10 minutes DHCPv6/v4 issues Stig Venaas 10 minutes Update on IPR issue with two drafts Ralph Droms 15 minutes Update of dhc WG charter Ralph Droms 15 minutes ----------- Total 105 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 2 15:56:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08663; Mon, 2 Feb 2004 15:56:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl6w-0006Zj-Fy; Mon, 02 Feb 2004 15:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl6k-0006V7-SM for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 15:55:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08494; Mon, 2 Feb 2004 15:55:48 -0500 (EST) Message-Id: <200402022055.PAA08494@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, 02 Feb 2004 15:55:47 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-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 : Client Identifier option in server replies Author(s) : N. Swamy Filename : draft-ietf-dhc-client-id-00.txt Pages : 4 Date : 2004-2-2 This document clarifies the use of 'client identifier' option by the clients and servers as mentioned in [RFC2131]. The clarification addresses the issue arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-client-id-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-client-id-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-client-id-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: <2004-2-2150138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-client-id-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-client-id-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150138.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 2 16:11:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10830; Mon, 2 Feb 2004 16:11: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 1AnlLS-0008S8-29; Mon, 02 Feb 2004 16: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 1AnlKX-0008Cv-2F for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 16:10:05 -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 QAA10421 for ; Mon, 2 Feb 2004 16:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnlKU-0001Tv-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 16:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnlJY-0001Lk-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 16:09:05 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AnlIx-0001F0-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 16:08:28 -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 855B21B9B95 for ; Mon, 2 Feb 2004 14:58:40 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <200402022055.PAA08494@ietf.org> References: <200402022055.PAA08494@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt Date: Mon, 2 Feb 2004 15:08:24 -0600 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.612) 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 > 3. Proposed modification to [RFC2131] > > If the 'client identifier' option is set in the message received > from > client, the server MUST return 'client identifier' value in its > response message. > > Following table is extracted from section 4.3.1 of [RFC2131] and > relevant fields are modified accordingly. > > Option DHCPOFFER DHCPACK DHCPNAK > ------ --------- ------- ------- > Client identifier MAY MAY MAY This is contradictory. I think if you're going to say MUST in the first paragraph, you need to say MUST in the table. You can put in a footnote that explains that if there is no client identifier, the server mustn't send one. :') I agree that MUST is the right answer here, by the way. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 2 20:11:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28514; Mon, 2 Feb 2004 20:11: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 1Anp5h-0003qu-Rb; Mon, 02 Feb 2004 20: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 1Anp4k-0003Wy-PP for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 20:10:02 -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 UAA28483 for ; Mon, 2 Feb 2004 20:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anp4i-0002LZ-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 20:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anp3l-0002GA-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 20:09:02 -0500 Received: from smtp103.mail.sc5.yahoo.com ([66.163.169.222]) by ietf-mx with smtp (Exim 4.12) id 1Anp39-0002Ah-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 20:08:23 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.145 with login) by smtp103.mail.sc5.yahoo.com with SMTP; 3 Feb 2004 01:08:23 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt Date: Mon, 2 Feb 2004 17:12:33 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) 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=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: if the "client identifier" MUST be returned (as the proposed modification suggests), then the supporting table also should contain the word "MUST" or, perhaps better, "MUST if in DHCPDISCOVER" --Barr > -----Original Message----- > > 3. Proposed modification to [RFC2131] > > > > If the 'client identifier' option is set in the message received > > from client, the server MUST return 'client identifier' value in > > its response message. > > > > Following table is extracted from section 4.3.1 of [RFC2131] and > > relevant fields are modified accordingly. > > > > Option DHCPOFFER DHCPACK DHCPNAK > > ------ --------- ------- ------- > > Client identifier MAY MAY MAY > [Ted Lemon] > This is contradictory. I think if you're going to say MUST in the > first paragraph, you need to say MUST in the table. You can put in a > footnote that explains that if there is no client identifier, the > server mustn't send one. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 2 20:34:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29685; Mon, 2 Feb 2004 20:34: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 1AnpRw-0005Ue-Uk; Mon, 02 Feb 2004 20:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpR1-0005So-Ps for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 20:33: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 UAA29641 for ; Mon, 2 Feb 2004 20:33:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnpQz-0004nK-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 20:33:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnpQ5-0004i1-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 20:32:05 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AnpPG-0004Wk-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 20:31:14 -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 <0HSH00801HV9LP@endeavor.poss.com> for dhcwg@ietf.org; Mon, 02 Feb 2004 20:30:40 -0500 (EST) Received: from kan1 (user56.net637.oh.sprint-hsd.net [65.41.58.56]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HSH00724IV1I1@endeavor.poss.com> for dhcwg@ietf.org; Mon, 02 Feb 2004 20:30:39 -0500 (EST) Date: Mon, 02 Feb 2004 20:30:24 -0500 From: "Kevin A. Noll" 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 Subject: [dhcwg] Options differing in OFFER and ACK 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'm trying to figure out how a client is expected to react if the server returns an IP address in the DHCPACK than what was offered in the DHCPOFFER (and requested by the client in the DHCPREQUEST). Following the general idea of DISCOVER-OFFER, REQUEST-ACK and the behavior implied for INIT-REBOOT, it seems that the most obvious way to handle this would be for the client to use the IP address returned in the DHCPACK, even if it is different than what was requested. However, there does not seem to be any specific resolution to this in RFC2131 or in draft-ietf-dhc-implementation-01. Can someone tell me if there is a specific answer to this? Is there a requirement that the server grant the IP address being requested if it was previously offered? --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 Mon Feb 2 21:52:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01964; Mon, 2 Feb 2004 21:52: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 1AnqfQ-0005iC-Sd; Mon, 02 Feb 2004 21:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnqeT-0005OY-7o for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 21:51: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 VAA01921 for ; Mon, 2 Feb 2004 21:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnqeQ-0004Pe-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 21:50:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnqdT-0004IM-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 21:49:59 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AnqcV-000451-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 21:48:59 -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 i132mk57051135 for ; Mon, 2 Feb 2004 21:48:54 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt Date: Mon, 2 Feb 2004 21:48:54 -0500 Message-ID: <000001c3ea00$463b0b00$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 Importance: Normal In-Reply-To: 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 agree but it would be nice if the table reflected both cases, such as: Option DHCPOFFER DHCPACK DHCPNAK ------ --------- ------- ------- Client identifier (if MUST MUST MUST sent by client) Client identifier (if MUST NOT MUST NOT MUST NOT not sent by client) Client identifier - if sent by client MUST MUST MUST - if not sent by client MUST NOT MUST NOT MUST NOT A footnote would be OK as well. Also, in section 3, it might be best to revise the text slightly, as follows? 3. Proposed modification to [RFC2131] If the 'client identifier' option is set in a message received from a client, the server MUST return the 'client identifier' option, unaltered, in its response message. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Barr Hibbs Sent: Monday, February 02, 2004 8:13 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt I agree: if the "client identifier" MUST be returned (as the proposed modification suggests), then the supporting table also should contain the word "MUST" or, perhaps better, "MUST if in DHCPDISCOVER" --Barr > -----Original Message----- > > 3. Proposed modification to [RFC2131] > > > > If the 'client identifier' option is set in the message received > > from client, the server MUST return 'client identifier' value in > > its response message. > > > > Following table is extracted from section 4.3.1 of [RFC2131] and > > relevant fields are modified accordingly. > > > > Option DHCPOFFER DHCPACK DHCPNAK > > ------ --------- ------- ------- > > Client identifier MAY MAY MAY > [Ted Lemon] > This is contradictory. I think if you're going to say MUST in the > first paragraph, you need to say MUST in the table. You can put in a > footnote that explains that if there is no client identifier, the > server mustn't send one. > _______________________________________________ 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 Mon Feb 2 22:07:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02460; Mon, 2 Feb 2004 22:07: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 1Anqtx-0006nx-Ij; Mon, 02 Feb 2004 22: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 1Anqt0-0006lo-M3 for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 22:06:02 -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 WAA02383 for ; Mon, 2 Feb 2004 22:05:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anqsx-0005zA-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:05:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anqry-0005qe-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:04:59 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Anqr1-0005jM-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:03:59 -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 68EC6591E3A; Mon, 2 Feb 2004 20:54:12 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <99CA3F48-55F5-11D8-9DEF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Options differing in OFFER and ACK Date: Mon, 2 Feb 2004 21:03:54 -0600 To: "Kevin A. Noll" X-Mailer: Apple Mail (2.612) 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 On Feb 2, 2004, at 7:30 PM, Kevin A. Noll wrote: > Can someone tell me if there is a specific answer to this? Is there > a requirement that the server grant the IP address being requested > if it was previously offered? This is a protocol violation on the part of the server. The client should drop the packet like a hot potato - it's probably a denial of service attack. I don't think 2131 is specific about cases like this. I tend to be in favor of interoperability over pickiness, but the server is totally forbidden from doing this in RFC2131, and I don't see any reason why the client should be forgiving about it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 2 22:07:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02492; Mon, 2 Feb 2004 22:07: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 1Anqu2-0006rU-U6; Mon, 02 Feb 2004 22:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnqtE-0006mb-Gf for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 22:06: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 WAA02443 for ; Mon, 2 Feb 2004 22:06:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnqtB-00060x-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:06:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnqsO-0005uk-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:05:25 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1Anqrs-0005mI-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:04:52 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.36 #1 (Debian)) id 1AnqrM-0006By-00; Mon, 02 Feb 2004 19:04:20 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Feb 2004 19:04:15 -0800 Message-ID: From: "Kostur, Andre" To: "'Kevin A. Noll'" , dhcwg@ietf.org Subject: RE: [dhcwg] Options differing in OFFER and ACK Date: Mon, 2 Feb 2004 19:04:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EA02.678A58E0" 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=AWL,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_01C3EA02.678A58E0 Content-Type: text/plain; charset="iso-8859-1" Huh? Not sure how that could happen: Client DISCOVERs Server OFFERs IP X Client REQUESTs w/ RequestedIP == X If the server isn't willing to assign X to the client, then it will NAK at this point. The server _is_ allowed to change its mind between the OFFER and the REQUEST. But if it's not willing to assign X, it must NAK. I don't have 2131 in front of me, so I can't quote the section it's in. > -----Original Message----- > From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] > Sent: Monday, February 02, 2004 5:30 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Options differing in OFFER and ACK > > > > > I'm trying to figure out how a client is expected to react if the > server returns an IP address in the DHCPACK than what was offered > in the DHCPOFFER (and requested by the client in the DHCPREQUEST). > > Following the general idea of DISCOVER-OFFER, REQUEST-ACK and the > behavior implied for INIT-REBOOT, it seems that the most obvious > way to handle this would be for the client to use the IP address > returned in the DHCPACK, even if it is different than what was > requested. However, there does not seem to be any specific resolution > to this in RFC2131 or in draft-ietf-dhc-implementation-01. > > Can someone tell me if there is a specific answer to this? Is there > a requirement that the server grant the IP address being requested > if it was previously offered? ------_=_NextPart_001_01C3EA02.678A58E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Options differing in OFFER and ACK

Huh? Not sure how that could happen:

Client DISCOVERs
Server OFFERs IP X
Client REQUESTs w/ RequestedIP =3D=3D X

If the server isn't willing to assign X to the = client, then it will NAK at this point.  The server _is_ allowed = to change its mind between the OFFER and the REQUEST.  But if it's = not willing to assign X, it must NAK.  I don't have 2131 in front = of me, so I can't quote the section it's in.

> -----Original Message-----
> From: Kevin A. Noll [mailto:kevin.noll@perfectord= er.com]
> Sent: Monday, February 02, 2004 5:30 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Options differing in OFFER and = ACK
>
>
>
>
> I'm trying to figure out how a client is = expected to react if the
> server returns an IP address in the DHCPACK = than what was offered
> in the DHCPOFFER (and requested by the client = in the DHCPREQUEST).
>
> Following the general idea of DISCOVER-OFFER, = REQUEST-ACK and the
> behavior implied for INIT-REBOOT, it seems that = the most obvious
> way to handle this would be for the client to = use the IP address
> returned in the DHCPACK, even if it is = different than what was
> requested. However, there does not seem to be = any specific resolution
> to this in RFC2131 or in = draft-ietf-dhc-implementation-01.
>
> Can someone tell me if there is a specific = answer to this? Is there
> a requirement that the server grant the IP = address being requested
> if it was previously offered?

------_=_NextPart_001_01C3EA02.678A58E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 2 22:30:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03370; Mon, 2 Feb 2004 22:30: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 1AnrGE-0001NW-Vs; Mon, 02 Feb 2004 22: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 1AnrFI-0001Fh-BY for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 22:29: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 WAA03331 for ; Mon, 2 Feb 2004 22:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnrFF-0000ga-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:29:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnrEJ-0000b5-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:28:04 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AnrDd-0000Rk-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:27:21 -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 <0HSH00F01MZJ5C@endeavor.poss.com> for dhcwg@ietf.org; Mon, 02 Feb 2004 22:26:52 -0500 (EST) Received: from kan1 (user56.net637.oh.sprint-hsd.net [65.41.58.56]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HSH007I0O8PI1@endeavor.poss.com>; Mon, 02 Feb 2004 22:26:51 -0500 (EST) Date: Mon, 02 Feb 2004 22:26:35 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] Options differing in OFFER and ACK In-reply-to: <99CA3F48-55F5-11D8-9DEF-000A95D9C74C@fugue.com> To: Ted Lemon Cc: 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 that it is not the correct behavior. What I'm looking for is a reference in 2131 that would say (or at least imply) that this is a violation of the protocol. --kan-- > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > Lemon > Sent: Monday, 02 February, 2004 10:04 PM > To: Kevin A. Noll > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Options differing in OFFER and ACK > > > On Feb 2, 2004, at 7:30 PM, Kevin A. Noll wrote: > > Can someone tell me if there is a specific answer to this? Is there > > a requirement that the server grant the IP address being requested > > if it was previously offered? > > This is a protocol violation on the part of the server. The client > should drop the packet like a hot potato - it's probably a denial of > service attack. > > I don't think 2131 is specific about cases like this. I tend to be in > favor of interoperability over pickiness, but the server is totally > forbidden from doing this in RFC2131, and I don't see any reason why > the client should be forgiving about it. > > > _______________________________________________ > 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 Mon Feb 2 22:30:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03371; Mon, 2 Feb 2004 22:30: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 1AnrGF-0001Ne-F8; Mon, 02 Feb 2004 22: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 1AnrFJ-0001Fn-TC for dhcwg@optimus.ietf.org; Mon, 02 Feb 2004 22:29:05 -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 WAA03334 for ; Mon, 2 Feb 2004 22:29:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnrFG-0000gp-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:29:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnrEK-0000bD-00 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:28:05 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AnrDd-0000Rk-01 for dhcwg@ietf.org; Mon, 02 Feb 2004 22:27:21 -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 <0HSH00F01MZJ5C@endeavor.poss.com> for dhcwg@ietf.org; Mon, 02 Feb 2004 22:27:15 -0500 (EST) Received: from kan1 (user56.net637.oh.sprint-hsd.net [65.41.58.56]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HSH007I6O9CI1@endeavor.poss.com>; Mon, 02 Feb 2004 22:27:13 -0500 (EST) Date: Mon, 02 Feb 2004 22:26:58 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] Options differing in OFFER and ACK In-reply-to: To: "Kostur, Andre" , 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: multipart/alternative; boundary="Boundary_(ID_tgebnX9+Ir8WPoILwIX+sg)" 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.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,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. --Boundary_(ID_tgebnX9+Ir8WPoILwIX+sg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT RE: [dhcwg] Options differing in OFFER and ACK A bug in the server? --kan-- -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Kostur, Andre Sent: Monday, 02 February, 2004 10:04 PM To: 'Kevin A. Noll'; dhcwg@ietf.org Subject: RE: [dhcwg] Options differing in OFFER and ACK Huh? Not sure how that could happen: Client DISCOVERs Server OFFERs IP X Client REQUESTs w/ RequestedIP == X If the server isn't willing to assign X to the client, then it will NAK at this point. The server _is_ allowed to change its mind between the OFFER and the REQUEST. But if it's not willing to assign X, it must NAK. I don't have 2131 in front of me, so I can't quote the section it's in. > -----Original Message----- > From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] > Sent: Monday, February 02, 2004 5:30 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Options differing in OFFER and ACK > > > > > I'm trying to figure out how a client is expected to react if the > server returns an IP address in the DHCPACK than what was offered > in the DHCPOFFER (and requested by the client in the DHCPREQUEST). > > Following the general idea of DISCOVER-OFFER, REQUEST-ACK and the > behavior implied for INIT-REBOOT, it seems that the most obvious > way to handle this would be for the client to use the IP address > returned in the DHCPACK, even if it is different than what was > requested. However, there does not seem to be any specific resolution > to this in RFC2131 or in draft-ietf-dhc-implementation-01. > > Can someone tell me if there is a specific answer to this? Is there > a requirement that the server grant the IP address being requested > if it was previously offered? --Boundary_(ID_tgebnX9+Ir8WPoILwIX+sg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT RE: [dhcwg] Options differing in OFFER and ACK
 
A bug in the server?
 
--kan--
-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Kostur, Andre
Sent: Monday, 02 February, 2004 10:04 PM
To: 'Kevin A. Noll'; dhcwg@ietf.org
Subject: RE: [dhcwg] Options differing in OFFER and ACK

Huh? Not sure how that could happen:

Client DISCOVERs
Server OFFERs IP X
Client REQUESTs w/ RequestedIP == X

If the server isn't willing to assign X to the client, then it will NAK at this point.  The server _is_ allowed to change its mind between the OFFER and the REQUEST.  But if it's not willing to assign X, it must NAK.  I don't have 2131 in front of me, so I can't quote the section it's in.

> -----Original Message-----
> From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com]
> Sent: Monday, February 02, 2004 5:30 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Options differing in OFFER and ACK
>
>
>
>
> I'm trying to figure out how a client is expected to react if the
> server returns an IP address in the DHCPACK than what was offered
> in the DHCPOFFER (and requested by the client in the DHCPREQUEST).
>
> Following the general idea of DISCOVER-OFFER, REQUEST-ACK and the
> behavior implied for INIT-REBOOT, it seems that the most obvious
> way to handle this would be for the client to use the IP address
> returned in the DHCPACK, even if it is different than what was
> requested. However, there does not seem to be any specific resolution
> to this in RFC2131 or in draft-ietf-dhc-implementation-01.
>
> Can someone tell me if there is a specific answer to this? Is there
> a requirement that the server grant the IP address being requested
> if it was previously offered?

--Boundary_(ID_tgebnX9+Ir8WPoILwIX+sg)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 06:28:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03643; Tue, 3 Feb 2004 06:28: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 1Anyim-0001ug-2K; Tue, 03 Feb 2004 06:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anyi8-0001qg-UO for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 06:27:20 -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 GAA03549 for ; Tue, 3 Feb 2004 06:27:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anyi4-0002yc-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 06:27:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anyh4-0002no-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 06:26:14 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1Anyg8-0002cg-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 06:25:17 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i13BP6V12169 for ; Tue, 3 Feb 2004 18:25:07 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i13BMHk20316 for ; Tue, 3 Feb 2004 18:22:17 +0700 (ICT) From: Robert Elz To: dhcwg@ietf.org Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt In-Reply-To: <000001c3ea00$463b0b00$6401a8c0@BVolz> References: <000001c3ea00$463b0b00$6401a8c0@BVolz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Feb 2004 18:22:17 +0700 Message-ID: <197.1075807337@munnari.OZ.AU> 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Mon, 2 Feb 2004 21:48:54 -0500 From: "Bernie Volz" Message-ID: <000001c3ea00$463b0b00$6401a8c0@BVolz> | I agree but it would be nice if the table reflected both cases, such as: | | Option DHCPOFFER DHCPACK DHCPNAK | ------ --------- ------- ------- | Client identifier (if MUST MUST MUST | sent by client) | Client identifier (if MUST NOT MUST NOT MUST NOT | not sent by client) How about extending the words that can be used in the columns beyond the standard MAY/SHOULD/MUST (and inverses) set, and include things like DISCOVER & REQUEST which would be defined like DISCOVER: the option MUST be included if it was present in the DHCPDISCOVER packet, and MUST NOT be included if it was not. The value of the option MUST be set appropriately, which is not always to simply copy from the DHCPDISCOVER packet, though may be for particular options. (and similarly for REQUEST). Then the table could be Option DHCPOFFER DHCPACK DHCPNAK ------ --------- ------- ------- Client identifier DISCOVER REQUEST REQUEST (or whatever is appropriate). Perhaps some other options have the same kind of rules? kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 10:54:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15300; Tue, 3 Feb 2004 10:54:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2sD-0002D1-DQ; Tue, 03 Feb 2004 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2rh-0002CD-Qj for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 10:53: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 KAA15237 for ; Tue, 3 Feb 2004 10:53:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao2rf-0000xg-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 10:53:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao2ql-0000rd-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 10:52:31 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Ao2pu-0000lH-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 10:51:38 -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 C33141EFAD3; Tue, 3 Feb 2004 09:41:43 -0600 (CST) In-Reply-To: <000001c3ea00$463b0b00$6401a8c0@BVolz> References: <000001c3ea00$463b0b00$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt Date: Tue, 3 Feb 2004 09:51:35 -0600 To: "Bernie Volz" X-Mailer: Apple Mail (2.612) 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 On Feb 2, 2004, at 8:48 PM, Bernie Volz wrote: > I agree but it would be nice if the table reflected both cases, such > as: I'm okay with this way of representing it also. It's probably better in the sense that it's gives a first-class representation in the table to both scenarios. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 11:05:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15647; Tue, 3 Feb 2004 11:05: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 1Ao32t-0002dY-5u; Tue, 03 Feb 2004 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 1Ao32O-0002cH-Ta for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 11:04: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 LAA15622 for ; Tue, 3 Feb 2004 11:04:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao32M-00028C-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:04:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao31Y-00022v-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:03:41 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Ao30x-0001wU-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:03:03 -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 C54F097192D; Tue, 3 Feb 2004 09:53:10 -0600 (CST) In-Reply-To: <197.1075807337@munnari.OZ.AU> References: <000001c3ea00$463b0b00$6401a8c0@BVolz> <197.1075807337@munnari.OZ.AU> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71BBA40A-5662-11D8-9DEF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt Date: Tue, 3 Feb 2004 10:03:02 -0600 To: Robert Elz X-Mailer: Apple Mail (2.612) 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 > How about extending the words that can be used in the columns beyond > the standard MAY/SHOULD/MUST (and inverses) set, and include things > like DISCOVER & REQUEST which would be defined like What we want is that whenever the client sends a client-identifier option in a packet, the response from the server contains that client identifier. This is a very simple concept - there's no need for anything fancy. I like Bernie's table entries because they are a little clearer for the reader, but from the perspective of verbiage, as opposed to tables, this really only needs to be a single sentence, and I don't think additional complexity in the table is going to help clarify things for the reader - it will either not make a difference, or it will confuse the reader. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 11:13:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16055; Tue, 3 Feb 2004 11:13: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 1Ao3AZ-0003rz-WA; Tue, 03 Feb 2004 11:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3A3-0003pk-46 for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 11:12: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 LAA15994 for ; Tue, 3 Feb 2004 11:12:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3A1-0002zP-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:12:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao394-0002rP-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:11:27 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1Ao38G-0002g6-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:10:36 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.36 #1 (Debian)) id 1Ao37h-0005Lu-00; Tue, 03 Feb 2004 08:10:01 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 08:09:52 -0800 Message-ID: From: "Kostur, Andre" To: "'Ted Lemon'" , Robert Elz Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt Date: Tue, 3 Feb 2004 08:09:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EA70.27CABA60" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,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_01C3EA70.27CABA60 Content-Type: text/plain; charset="iso-8859-1" My $0.02, I'm a fan of Ted's original suggestion for the table: Option DHCPOFFER DHCPACK DHCPNAK ------ --------- ------- ------- Client identifier MUST* MUST* MUST* * - Only if the Client identifier was present in the client's packet Although some wording should probably be added to the effect that this also applies to RECONFIGURE messages (RFC 3203). > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com] > Sent: Tuesday, February 03, 2004 8:03 AM > To: Robert Elz > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt > > > > How about extending the words that can be used in the columns beyond > > the standard MAY/SHOULD/MUST (and inverses) set, and include things > > like DISCOVER & REQUEST which would be defined like > > What we want is that whenever the client sends a client-identifier > option in a packet, the response from the server contains that client > identifier. This is a very simple concept - there's no need for > anything fancy. I like Bernie's table entries because they are a > little clearer for the reader, but from the perspective of > verbiage, as > opposed to tables, this really only needs to be a single > sentence, and > I don't think additional complexity in the table is going to help > clarify things for the reader - it will either not make a difference, > or it will confuse the reader. ------_=_NextPart_001_01C3EA70.27CABA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt

My $0.02, I'm a fan of Ted's original suggestion for = the table:


Option         &nb= sp;          = DHCPOFFER    = DHCPACK           = ; DHCPNAK
------         &nb= sp;          = ---------    = -------           = ; -------
Client = identifier         = MUST*        = MUST*           &= nbsp;  MUST*

* - Only if the Client identifier was present in the = client's packet


Although some wording should probably be added to the = effect that this also applies to RECONFIGURE messages (RFC = 3203).

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@fugue.com]
> Sent: Tuesday, February 03, 2004 8:03 AM
> To: Robert Elz
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] I-D = ACTION:draft-ietf-dhc-client-id-00.txt
>
>
> > How about extending the words that can be = used in the columns beyond
> > the standard MAY/SHOULD/MUST (and = inverses) set, and include things
> > like DISCOVER & REQUEST which would be = defined like
>
> What we want is that whenever the client sends = a client-identifier
> option in a packet, the response from the = server contains that client
> identifier.   This is a very simple = concept - there's no need for
> anything fancy.   I like Bernie's = table entries because they are a
> little clearer for the reader, but from the = perspective of
> verbiage, as
> opposed to tables, this really only needs to be = a single
> sentence, and
> I don't think additional complexity in the = table is going to help
> clarify things for the reader - it will either = not make a difference,
> or it will confuse the reader.

------_=_NextPart_001_01C3EA70.27CABA60-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 11:35:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16856; Tue, 3 Feb 2004 11:35: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 1Ao3Vu-0005iD-FD; Tue, 03 Feb 2004 11: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 1Ao3VQ-0005fd-B3 for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 11:34: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 LAA16826 for ; Tue, 3 Feb 2004 11:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3VP-0005L7-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:34:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao3UV-0005Fl-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:33:35 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao3Tr-00058Q-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:32:55 -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 <0HSI00J01OCZUV@endeavor.poss.com> for dhcwg@ietf.org; Tue, 03 Feb 2004 11:32:25 -0500 (EST) Received: from kan1 (user56.net637.oh.sprint-hsd.net [65.41.58.56]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HSI00ET1OLXJG@endeavor.poss.com>; Tue, 03 Feb 2004 11:32:24 -0500 (EST) Date: Tue, 03 Feb 2004 11:32:05 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] Options differing in OFFER and ACK In-reply-to: To: Ted Lemon Cc: 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=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 suppose this paragraph in item 4 of section 3.1 would imply the protocol violation... If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message. I suppose my confusion is that 2131 doesn't give any guidance about what the client is to do in this case. --kan-- > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Kevin A. Noll > Sent: Monday, 02 February, 2004 10:27 PM > To: Ted Lemon > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Options differing in OFFER and ACK > > > > I agree that it is not the correct behavior. > > What I'm looking for is a reference in 2131 that would say (or at > least imply) that this is a violation of the protocol. > > --kan-- > > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > > Lemon > > Sent: Monday, 02 February, 2004 10:04 PM > > To: Kevin A. Noll > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] Options differing in OFFER and ACK > > > > > > On Feb 2, 2004, at 7:30 PM, Kevin A. Noll wrote: > > > Can someone tell me if there is a specific answer to this? Is there > > > a requirement that the server grant the IP address being requested > > > if it was previously offered? > > > > This is a protocol violation on the part of the server. The client > > should drop the packet like a hot potato - it's probably a denial of > > service attack. > > > > I don't think 2131 is specific about cases like this. I tend to be in > > favor of interoperability over pickiness, but the server is totally > > forbidden from doing this in RFC2131, and I don't see any reason why > > the client should be forgiving about it. > > > > > > _______________________________________________ > > 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 Feb 3 11:44:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17342; Tue, 3 Feb 2004 11:44: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 1Ao3eb-0006aG-Ha; Tue, 03 Feb 2004 11: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 1Ao3e6-0006Zb-6h for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 11:43:30 -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 LAA17296 for ; Tue, 3 Feb 2004 11:43:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3e4-0006Bi-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:43:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao3d8-00066n-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:42:31 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3ch-00061x-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:42:03 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.36 #1 (Debian)) id 1Ao3cA-0005nH-00; Tue, 03 Feb 2004 08:41:30 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 08:41:25 -0800 Message-ID: From: "Kostur, Andre" To: "'Kevin A. Noll'" , Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Options differing in OFFER and ACK Date: Tue, 3 Feb 2004 08:41:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EA74.8FD65480" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,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_01C3EA74.8FD65480 Content-Type: text/plain; charset="iso-8859-1" Look in section 4.4, the state diagram. If the client receives a NAK in the Requesting state, it is to discard the offer, and transition back into the Init state. If this was an Init-Reboot, and the client is in the Rebooting state, it is to "Restart" and transition to the Init state. Nutshell version: if you get a NAK at this point, your current lease (or the offered lease) is no longer valid. Go back to Discover. > -----Original Message----- > From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] > Sent: Tuesday, February 03, 2004 8:32 AM > To: Ted Lemon > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Options differing in OFFER and ACK > > I suppose this paragraph in item 4 of section 3.1 would imply > the protocol > violation... > > If the selected server is unable to satisfy the > DHCPREQUEST message > (e.g., the requested network address has been allocated), the > server SHOULD respond with a DHCPNAK message. > > I suppose my confusion is that 2131 doesn't give any guidance > about what > the client is to do in this case. > > --kan-- > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > > Kevin A. Noll > > Sent: Monday, 02 February, 2004 10:27 PM > > To: Ted Lemon > > Cc: dhcwg@ietf.org > > Subject: RE: [dhcwg] Options differing in OFFER and ACK > > > > I agree that it is not the correct behavior. > > > > What I'm looking for is a reference in 2131 that would say (or at > > least imply) that this is a violation of the protocol. > > > > > -----Original Message----- > > > From: dhcwg-admin@ietf.org > [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > > > Lemon > > > Sent: Monday, 02 February, 2004 10:04 PM > > > To: Kevin A. Noll > > > Cc: dhcwg@ietf.org > > > Subject: Re: [dhcwg] Options differing in OFFER and ACK > > > > > > > > > On Feb 2, 2004, at 7:30 PM, Kevin A. Noll wrote: > > > > Can someone tell me if there is a specific answer to > this? Is there > > > > a requirement that the server grant the IP address > being requested > > > > if it was previously offered? > > > > > > This is a protocol violation on the part of the server. > The client > > > should drop the packet like a hot potato - it's probably > a denial of > > > service attack. > > > > > > I don't think 2131 is specific about cases like this. I > tend to be in > > > favor of interoperability over pickiness, but the server > is totally > > > forbidden from doing this in RFC2131, and I don't see any > reason why > > > the client should be forgiving about it. ------_=_NextPart_001_01C3EA74.8FD65480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Options differing in OFFER and ACK

Look in section 4.4, the state diagram.  If the = client receives a NAK in the Requesting state, it is to discard the = offer, and transition back into the Init state.  If this was an = Init-Reboot, and the client is in the Rebooting state, it is to = "Restart" and transition to the Init state.

Nutshell version: if you get a NAK at this point, = your current lease (or the offered lease) is no longer valid.  Go = back to Discover.

> -----Original Message-----
> From: Kevin A. Noll [mailto:kevin.noll@perfectord= er.com]
> Sent: Tuesday, February 03, 2004 8:32 AM
> To: Ted Lemon
> Cc: dhcwg@ietf.org
> Subject: RE: [dhcwg] Options differing in OFFER = and ACK
>
> I suppose this paragraph in item 4 of section = 3.1 would imply
> the protocol
> violation...
>
>      If the selected = server is unable to satisfy the
> DHCPREQUEST message
>      (e.g., the = requested network address has been allocated), the
>      server SHOULD = respond with a DHCPNAK message.
>
> I suppose my confusion is that 2131 doesn't = give any guidance
> about what
> the client is to do in this case.
>
> --kan--
>
> > -----Original Message-----
> > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On = Behalf Of
> > Kevin A. Noll
> > Sent: Monday, 02 February, 2004 10:27 = PM
> > To: Ted Lemon
> > Cc: dhcwg@ietf.org
> > Subject: RE: [dhcwg] Options differing in = OFFER and ACK
> >
> > I agree that it is not the correct = behavior.
> >
> > What I'm looking for is a reference in = 2131 that would say (or at
> > least imply) that this is a violation of = the protocol.
> >
> > > -----Original Message-----
> > > From: dhcwg-admin@ietf.org
> [mailto:dhcwg-admin@ietf.org]On = Behalf Of Ted
> > > Lemon
> > > Sent: Monday, 02 February, 2004 10:04 = PM
> > > To: Kevin A. Noll
> > > Cc: dhcwg@ietf.org
> > > Subject: Re: [dhcwg] Options = differing in OFFER and ACK
> > >
> > >
> > > On Feb 2, 2004, at 7:30 PM, Kevin A. = Noll wrote:
> > > > Can someone tell me if there is = a specific answer to
> this? Is there
> > > > a requirement that the server = grant the IP address
> being requested
> > > > if it was previously = offered?
> > >
> > > This is a protocol violation on the = part of the server.  
> The client
> > > should drop the packet like a hot = potato - it's probably
> a denial of
> > > service attack.
> > >
> > > I don't think 2131 is specific about = cases like this.   I
> tend to be in
> > > favor of interoperability over = pickiness, but the server
> is totally
> > > forbidden from doing this in RFC2131, = and I don't see any
> reason why
> > > the client should be forgiving about = it.

------_=_NextPart_001_01C3EA74.8FD65480-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 11:57:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17973; Tue, 3 Feb 2004 11:57: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 1Ao3rB-0007Y6-OO; Tue, 03 Feb 2004 11: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 1Ao3qi-0007XC-Cr for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 11:56: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 LAA17882 for ; Tue, 3 Feb 2004 11:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3qh-0007Xk-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:56:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao3pq-0007St-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:55:40 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao3pI-0007Km-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 11:55:04 -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 <0HSI00M01PGK0I@endeavor.poss.com> for dhcwg@ietf.org; Tue, 03 Feb 2004 11:54:35 -0500 (EST) Received: from kan1 (user56.net637.oh.sprint-hsd.net [65.41.58.56]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HSI00E3YPMSJG@endeavor.poss.com>; Tue, 03 Feb 2004 11:54:33 -0500 (EST) Date: Tue, 03 Feb 2004 11:54:13 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] Options differing in OFFER and ACK In-reply-to: To: "Kostur, Andre" , Ted Lemon Cc: 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: multipart/alternative; boundary="Boundary_(ID_28cm8K6V73o/4LbXLhzqfA)" 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.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,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. --Boundary_(ID_28cm8K6V73o/4LbXLhzqfA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT RE: [dhcwg] Options differing in OFFER and ACK Yep, I understand this scenario. What I'm missing is if the client receives an ACK, but the ACKed IP is different than the OFFERed IP. Seems to me that the client should drop the ACK (like Ted suggests), or send a DHCPDECLINE. I just don't see any recommendation for this. --kan-- -----Original Message----- From: Kostur, Andre [mailto:Andre@incognito.com] Sent: Tuesday, 03 February, 2004 11:41 AM To: 'Kevin A. Noll'; Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Options differing in OFFER and ACK Look in section 4.4, the state diagram. If the client receives a NAK in the Requesting state, it is to discard the offer, and transition back into the Init state. If this was an Init-Reboot, and the client is in the Rebooting state, it is to "Restart" and transition to the Init state. Nutshell version: if you get a NAK at this point, your current lease (or the offered lease) is no longer valid. Go back to Discover. > -----Original Message----- > From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] > Sent: Tuesday, February 03, 2004 8:32 AM > To: Ted Lemon > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Options differing in OFFER and ACK > > I suppose this paragraph in item 4 of section 3.1 would imply > the protocol > violation... > > If the selected server is unable to satisfy the > DHCPREQUEST message > (e.g., the requested network address has been allocated), the > server SHOULD respond with a DHCPNAK message. > > I suppose my confusion is that 2131 doesn't give any guidance > about what > the client is to do in this case. > > --kan-- > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > > Kevin A. Noll > > Sent: Monday, 02 February, 2004 10:27 PM > > To: Ted Lemon > > Cc: dhcwg@ietf.org > > Subject: RE: [dhcwg] Options differing in OFFER and ACK > > > > I agree that it is not the correct behavior. > > > > What I'm looking for is a reference in 2131 that would say (or at > > least imply) that this is a violation of the protocol. > > > > > -----Original Message----- > > > From: dhcwg-admin@ietf.org > [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > > > Lemon > > > Sent: Monday, 02 February, 2004 10:04 PM > > > To: Kevin A. Noll > > > Cc: dhcwg@ietf.org > > > Subject: Re: [dhcwg] Options differing in OFFER and ACK > > > > > > > > > On Feb 2, 2004, at 7:30 PM, Kevin A. Noll wrote: > > > > Can someone tell me if there is a specific answer to > this? Is there > > > > a requirement that the server grant the IP address > being requested > > > > if it was previously offered? > > > > > > This is a protocol violation on the part of the server. > The client > > > should drop the packet like a hot potato - it's probably > a denial of > > > service attack. > > > > > > I don't think 2131 is specific about cases like this. I > tend to be in > > > favor of interoperability over pickiness, but the server > is totally > > > forbidden from doing this in RFC2131, and I don't see any > reason why > > > the client should be forgiving about it. --Boundary_(ID_28cm8K6V73o/4LbXLhzqfA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT RE: [dhcwg] Options differing in OFFER and ACK
 
Yep, I understand this scenario.
 
What I'm missing is if the client receives an ACK, but the ACKed IP is different than
the OFFERed IP.
 
Seems to me that the client should drop the ACK (like Ted suggests), or send a
DHCPDECLINE. I just don't see any recommendation for this.
 
--kan--
-----Original Message-----
From: Kostur, Andre [mailto:Andre@incognito.com]
Sent: Tuesday, 03 February, 2004 11:41 AM
To: 'Kevin A. Noll'; Ted Lemon
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Options differing in OFFER and ACK

Look in section 4.4, the state diagram.  If the client receives a NAK in the Requesting state, it is to discard the offer, and transition back into the Init state.  If this was an Init-Reboot, and the client is in the Rebooting state, it is to "Restart" and transition to the Init state.

Nutshell version: if you get a NAK at this point, your current lease (or the offered lease) is no longer valid.  Go back to Discover.

> -----Original Message-----
> From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com]
> Sent: Tuesday, February 03, 2004 8:32 AM
> To: Ted Lemon
> Cc: dhcwg@ietf.org
> Subject: RE: [dhcwg] Options differing in OFFER and ACK
>
> I suppose this paragraph in item 4 of section 3.1 would imply
> the protocol
> violation...
>
>      If the selected server is unable to satisfy the
> DHCPREQUEST message
>      (e.g., the requested network address has been allocated), the
>      server SHOULD respond with a DHCPNAK message.
>
> I suppose my confusion is that 2131 doesn't give any guidance
> about what
> the client is to do in this case.
>
> --kan--
>
> > -----Original Message-----
> > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
> > Kevin A. Noll
> > Sent: Monday, 02 February, 2004 10:27 PM
> > To: Ted Lemon
> > Cc: dhcwg@ietf.org
> > Subject: RE: [dhcwg] Options differing in OFFER and ACK
> >
> > I agree that it is not the correct behavior.
> >
> > What I'm looking for is a reference in 2131 that would say (or at
> > least imply) that this is a violation of the protocol.
> >
> > > -----Original Message-----
> > > From: dhcwg-admin@ietf.org
> [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted
> > > Lemon
> > > Sent: Monday, 02 February, 2004 10:04 PM
> > > To: Kevin A. Noll
> > > Cc: dhcwg@ietf.org
> > > Subject: Re: [dhcwg] Options differing in OFFER and ACK
> > >
> > >
> > > On Feb 2, 2004, at 7:30 PM, Kevin A. Noll wrote:
> > > > Can someone tell me if there is a specific answer to
> this? Is there
> > > > a requirement that the server grant the IP address
> being requested
> > > > if it was previously offered?
> > >
> > > This is a protocol violation on the part of the server.  
> The client
> > > should drop the packet like a hot potato - it's probably
> a denial of
> > > service attack.
> > >
> > > I don't think 2131 is specific about cases like this.   I
> tend to be in
> > > favor of interoperability over pickiness, but the server
> is totally
> > > forbidden from doing this in RFC2131, and I don't see any
> reason why
> > > the client should be forgiving about it.

--Boundary_(ID_28cm8K6V73o/4LbXLhzqfA)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 12:03:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18253; Tue, 3 Feb 2004 12:03:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3w1-0008CR-QH; Tue, 03 Feb 2004 12:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3vZ-00083d-5M for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 12:01: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 MAA18196 for ; Tue, 3 Feb 2004 12:01:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3vX-0000Cp-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 12:01:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao3uc-00007n-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 12:00:35 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3uM-00002G-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 12:00:18 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.36 #1 (Debian)) id 1Ao3tp-00064I-00; Tue, 03 Feb 2004 08:59:45 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 08:59:40 -0800 Message-ID: From: "Kostur, Andre" To: "'Kevin A. Noll'" , Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Options differing in OFFER and ACK Date: Tue, 3 Feb 2004 08:59:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EA77.1C92DAE0" 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=AWL,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_01C3EA77.1C92DAE0 Content-Type: text/plain; charset="iso-8859-1" The client probably should drop the packet, and assume it's a malformed DHCP packet. I don't think a DECLINE is really appropriate here since this isn't even the same IP as what was OFFERed. The client can't really be sure that this was a valid DHCP transaction since it violates protocol.... -----Original Message----- From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] Sent: Tuesday, February 03, 2004 8:54 AM To: Kostur, Andre; Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Options differing in OFFER and ACK Yep, I understand this scenario. What I'm missing is if the client receives an ACK, but the ACKed IP is different than the OFFERed IP. Seems to me that the client should drop the ACK (like Ted suggests), or send a DHCPDECLINE. I just don't see any recommendation for this. ------_=_NextPart_001_01C3EA77.1C92DAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Options differing in OFFER and ACK

The client probably should drop the packet, and = assume it's a malformed DHCP packet.  I don't think a DECLINE is = really appropriate here since this isn't even the same IP as what was = OFFERed.  The client can't really be sure that this was a valid = DHCP transaction since it violates protocol....

-----Original Message-----
From: Kevin A. Noll [mailto:kevin.noll@perfectord= er.com]
Sent: Tuesday, February 03, 2004 8:54 AM
To: Kostur, Andre; Ted Lemon
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Options differing in OFFER and = ACK


Yep, I understand this scenario.

What I'm missing is if the client receives an ACK, = but the ACKed IP is different than
the OFFERed IP.

Seems to me that the client should drop the ACK (like = Ted suggests), or send a
DHCPDECLINE. I just don't see any recommendation for = this.

------_=_NextPart_001_01C3EA77.1C92DAE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 12:46:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20857; Tue, 3 Feb 2004 12:46: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 1Ao4cb-00065F-HL; Tue, 03 Feb 2004 12: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 1Ao4c7-00063U-T5 for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 12:45: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 MAA20780 for ; Tue, 3 Feb 2004 12:45:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4c6-0005eV-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 12:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4bA-0005YZ-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 12:44:33 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4aJ-0005SJ-00 for dhcwg@ietf.org; Tue, 03 Feb 2004 12:43:39 -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 180B41C15E2; Tue, 3 Feb 2004 11:33:44 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7DE4F508-5670-11D8-9DEF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "Kostur, Andre" From: Ted Lemon Subject: Re: [dhcwg] Options differing in OFFER and ACK Date: Tue, 3 Feb 2004 11:43:35 -0600 To: "Kevin A. Noll" X-Mailer: Apple Mail (2.612) 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 On Feb 3, 2004, at 10:54 AM, Kevin A. Noll wrote: > Seems to me that the client should drop the ACK (like Ted suggests), > or send a > DHCPDECLINE. I just don't see any recommendation for this. It's a completely inappropriate packet. Sending a DHCPDECLINE in this case would be a very bad idea, because if it is a DoS attack, now the client is helping out, and might be able to squeak by a filter that would have prevented a direct attack on the server. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 3 15:46:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00120; Tue, 3 Feb 2004 15:46: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 1Ao7Qn-00088a-Fy; Tue, 03 Feb 2004 15: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 1Ao7Pt-00085g-Ib for dhcwg@optimus.ietf.org; Tue, 03 Feb 2004 15:45:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29921; Tue, 3 Feb 2004 15:45:03 -0500 (EST) Message-Id: <200402032045.PAA29921@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, 03 Feb 2004 15:45:02 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-mipadvert-opt-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 : DHCP Option for Mobile IP Mobility Agents Author(s) : H. Levkowetz Filename : draft-ietf-dhc-mipadvert-opt-02.txt Pages : 15 Date : 2004-2-3 This document defines a Dynamic Host Configuration Protocol (DHCP) option with sub-options. One sub-option is passed from the DHCP Server to the DHCP Client to announce the presence of one or more Mobile IP Mobility Agents. For each announced Mobility Agent, information is provided which is the same as that of the Mobile IP Agent Advertisement extension to ICMP Router Advertisements. There is also one sub-option which may be used by a DHCP client to provide identity information to the DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-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-mipadvert-opt-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-mipadvert-opt-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: <2004-2-3145908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-mipadvert-opt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-mipadvert-opt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-3145908.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 Feb 4 03:45:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26043; Wed, 4 Feb 2004 03:45: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 1AoIeb-0002ZX-VM; Wed, 04 Feb 2004 03:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIeY-0002ZH-OY for dhcwg@optimus.ietf.org; Wed, 04 Feb 2004 03:44:58 -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 DAA25988 for ; Wed, 4 Feb 2004 03:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoIeW-0006qf-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 03:44:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoIdX-0006jU-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 03:43:56 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1AoIcb-0006ZW-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 03:42:58 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i148gif08794; Wed, 4 Feb 2004 15:42:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i148gIX15893; Wed, 4 Feb 2004 15:42:19 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt In-Reply-To: <71BBA40A-5662-11D8-9DEF-000A95D9C74C@fugue.com> References: <71BBA40A-5662-11D8-9DEF-000A95D9C74C@fugue.com> <000001c3ea00$463b0b00$6401a8c0@BVolz> <197.1075807337@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Feb 2004 15:42:18 +0700 Message-ID: <17359.1075884138@munnari.OZ.AU> 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Tue, 3 Feb 2004 10:03:02 -0600 From: Ted Lemon Message-ID: <71BBA40A-5662-11D8-9DEF-000A95D9C74C@fugue.com> | What we want is that whenever the client sends a client-identifier | option in a packet, the response from the server contains that client | identifier. This is a very simple concept - there's no need for | anything fancy. If this is just for client identifier, and no other option either is, or ever will be, treated the same, then I agree. On the other hand, if there get to be 2, 3, 4 ... options that the server is expected to copy back into the reply, or to include in the reply (perhaps in modified form) whenever they appear in a discover/request, then I suspect that creating a common way to make that clear would be a better idea. But, whatever works... kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 4 12:28:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15884; Wed, 4 Feb 2004 12:28: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 1AoQom-0004kO-8K; Wed, 04 Feb 2004 12:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQoI-0004fh-Ny for dhcwg@optimus.ietf.org; Wed, 04 Feb 2004 12:27:34 -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 MAA15754 for ; Wed, 4 Feb 2004 12:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQoH-0005AE-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 12:27:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQnL-000521-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 12:26:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AoQmm-0004tV-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 12:26:00 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 04 Feb 2004 09:25:36 -0800 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 i14HPRXi014099 for ; Wed, 4 Feb 2004 12:25:27 -0500 (EST) Received: from mjs-xp.cisco.com (dhcp-10-86-160-215.cisco.com [10.86.160.215]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFU71314; Wed, 4 Feb 2004 12:25:26 -0500 (EST) Message-Id: <4.3.2.7.2.20040204121546.01bf6130@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Feb 2004 12:24:57 -0500 To: dhcwg@ietf.org From: Mark Stapp 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.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] vendor-specific relay suboption 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: , Vendor-specific capabilities seem to me to be a useful addition to the relay information data, so I've published (as an individual submission) a draft defining a vendor-specific relay suboption. I liked and have re-used the self-identifying method that Josh used in his vendor-identifying vendor-specific option drafts. I'd like to ask the WG to consider adopting this draft as a WG item. Here's a link to the initial version; please take a look and offer feedback. http://www.ietf.org/internet-drafts/draft-stapp-dhc-vendor-suboption-00.txt Thanks, Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 4 12:48:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17362; Wed, 4 Feb 2004 12:48: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 1AoR85-0006my-4Q; Wed, 04 Feb 2004 12: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 1AoR7N-0006gl-80 for dhcwg@optimus.ietf.org; Wed, 04 Feb 2004 12:47: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 MAA17263 for ; Wed, 4 Feb 2004 12:47:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoR7L-00002G-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 12:47:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoR6N-0007ij-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 12:46:15 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AoR5O-0007Vj-00; Wed, 04 Feb 2004 12:45:14 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 04 Feb 2004 09:44:50 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i14Hidlv001746; Wed, 4 Feb 2004 12:44:41 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-181.cisco.com [10.86.242.181]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFU73113; Wed, 4 Feb 2004 12:44:39 -0500 (EST) Message-Id: <4.3.2.7.2.20040204124237.01ea6ca8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Feb 2004 12:44:36 -0500 To: agenda@ietf.org From: Ralph Droms Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_101893354==_" 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 Subject: [dhcwg] Draft agenda for dhc WG meeting in Seoul 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: , --=====================_101893354==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please publish the attached draft agenda for the dhc WG meeting in Seoul. Thanks... - Ralph Droms --=====================_101893354==_ Content-Type: text/plain; name="agenda-out.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="agenda-out.txt" Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgICAgICAgICBESEMgV0cgYWdlbmRhIC0gSUVURiA1OQogICAgICAg ICAgICAgICAgICAgICAgMDkwMCBUdWUgMDMvMDQvMjAwNCAodGVudGF0aXZlKQogICAgICAgICAg ICAgICAgICAgICAoTGFzdCByZXZpc2VkIDAyLzA0LzIwMDQgMTI6MzcgUE0pCiAgICAgICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkFkbWluaXN0cml2 aWEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJhbHBoIERyb21zICAgICAg MDUgbWludXRlcwogIEFnZW5kYSBiYXNoaW5nCgpESENQIE9wdGlvbiBmb3IgUHJveHkgU2VydmVy IENvbmZpZ3VyYXRpb24gICAgICAgICA8VEJEPiAgICAgICAgICAgIDA1IG1pbnV0ZXMKICA8ZHJh ZnQtaWV0Zi1kaGMtcHJveHlzZXJ2ZXItb3B0LTAwLnR4dD4KClRoZSBFeHRlbmRlZCBSZW1vdGUg Qm9vdCBPcHRpb24gZm9yIERIQ1B2NCAgICAgICAgIDxUQkQ+ICAgICAgICAgICAgMDUgbWludXRl cwogIDxkcmFmdC1pZXRmLWRoYy1vcHQtZXh0cmJvb3QtMDAudHh0PgoKREhDUHY2IFN1cHBvcnQg Zm9yIFJlbW90ZSBCb290ICAgICAgICAgICAgICAgICAgICAgPFRCRD4gICAgICAgICAgICAwNSBt aW51dGVzCiAgPGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1vcHQtcmJvb3QtMDAudHh0PgoKQ29uZmln dXJlZCBUdW5uZWwgRW5kIFBvaW50IE9wdGlvbiBmb3IgREhDUHY2ICAgICAgRGFuaWVsIFBhcmsg ICAgICAwNSBtaW51dGVzCiAgPGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1jdGVwLW9wdC0wMS50eHQ+ CgpESENQdjQgU3VwcG9ydCBmb3IgQ29uZmlndXJpbmcgSVB2Ni1pbi1JUHY0IFR1bm5lbHMgRGFu aWVsIFBhcmsgICAgICAwNSBtaW51dGVzCiAgPGRyYWZ0LWRhbmllbC1kaGMtaXB2NmluNC10dW5u ZWxzLTAwLnR4dD4KClJlcXVpcmVtZW50cyBmb3IgUHJvcG9zZWQgQ2hhbmdlcyB0byBESENQdjQg ICAgICAgIDxUQkQ+ICAgICAgICAgICAgMDUgbWludXRlcwogIDxkcmFmdC1pZXRmLWRoYy1jaGFu Z2VzLTAwLnR4dD4KCk5vZGUtU3BlY2lmaWMgQ2xpZW50IElkZW50aWZpZXJzIGZvciBESENQdjQg ICAgICAgIDxUQkQ+ICAgICAgICAgICAgMDUgbWludXRlcwogIDxkcmFmdC1pZXRmLWRoYy0zMzE1 aWQtZm9yLXY0LTAxLnR4dD4KClJhcGlkIENvbW1pdCBPcHRpb24gZm9yIERIQ1B2NCAgICAgICAg ICAgICAgICAgICAgIDxUQkQ+ICAgICAgICAgICAgMDUgbWludXRlcwogIDxkcmFmdC1pZXRmLWRo Yy1yYXBpZC1jb21taXQtb3B0LTAwLnR4dD4KCk1pY3JvLWJsb2NrIElQIEFkZHJlc3MgQWxsb2Nh dGlvbiBXaXRoIERIQ1AgUHJveHkgU2VydmVyIE5haW1pbmcgU2hlbiAgICAgMDUgbWludXRlcwog IDxkcmFmdC1zaGVuLWRoYy1ibG9jay1hbGxvYy0wMS50eHQ+CgpSZW51bWJlcmluZyBSZXF1aXJl bWVudHMgZm9yIFN0YXRlbGVzcyBESENQdjYgICAgICBTdGlnIFZlbmFhcyAgICAgIDEwIG1pbnV0 ZXMKICA8ZHJhZnQtY2hvd24tZGhjLXN0YXRlbGVzcy1kaGNwdjYtcmVudW1iZXJpbmctMDAudHh0 PgoKTGlmZXRpbWUgT3B0aW9uIGZvciBESENQdjYgICAgICAgICAgICAgICAgICAgICAgICAgU3Rp ZyBWZW5hYXMgICAgICAxMCBtaW51dGVzCiAgPGRyYWZ0LXZlbmFhcy1kaGMtbGlmZXRpbWUtMDEu dHh0PgoKVmVuZG9yLVNwZWNpZmljIFN1Ym9wdGlvbiBmb3IgdGhlIERIQ1AgUmVsYXkgQWdlbnQg T3B0aW9uIDxUQkQ+ICAgICAgICAgICAgMDUgbWludXRlcwogIDxkcmFmdC1zdGFwcC1kaGMtdmVu ZG9yLXN1Ym9wdGlvbi0wMC50eHQ+CgpESENQdjYvdjQgaXNzdWVzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTdGlnIFZlbmFhcyAgICAgIDEwIG1pbnV0ZXMKClVwZGF0ZSBvbiBJ UFIgaXNzdWUgd2l0aCB0d28gZHJhZnRzICAgICAgICAgICAgICAgIFJhbHBoIERyb21zICAgICAg MTUgbWludXRlcwoKVXBkYXRlIG9mIGRoYyBXRyBjaGFydGVyICAgICAgICAgICAgICAgICAgICAg ICAgICAgUmFscGggRHJvbXMgICAgICAxNSBtaW51dGVzCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLQpU b3RhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgMTE1IG1pbnV0ZXMK --=====================_101893354==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 4 17:20:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04382; Wed, 4 Feb 2004 17:20: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 1AoVNK-0004je-OG; Wed, 04 Feb 2004 17:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVMz-0004iR-CZ for dhcwg@optimus.ietf.org; Wed, 04 Feb 2004 17:19: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 RAA04289 for ; Wed, 4 Feb 2004 17:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVMx-0000KS-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 17:19:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVM5-00009L-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 17:18:45 -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 1AoVKx-0007bC-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 17:17:35 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Feb 2004 14:24:01 +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 i14MH3fG005612 for ; Wed, 4 Feb 2004 14:17:04 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-223.cisco.com [10.82.240.223]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFV02887; Wed, 4 Feb 2004 17:17:02 -0500 (EST) Message-Id: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Feb 2004 17:16:55 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] 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: , The IESG has one remaining comment on this draft (see https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=896&filename=draft-ietf-dhc-dhcpv6-opt-nisconfig): what does a DHCPv6 server do when it wants to indicate that there's a NIS server available with an IPv4 address and another NIS server available with an IPv6 address? The two reasons why this can be a silly question: - NIS wouldn't work with such a config, so all the servers' addresses obviously have to be one address type - You can always encode a v4 address as a v6 address using the 96-zeroes convention (or something else), so it's obvious how to do it But I think the document should address the issue. We have a couple of alternatives to addressing the issue: 1. Reserve DHCPv6 for IPv6 NIS servers and DHCPv4 for IPv4 NIS servers 2. Wait until the WG completes its work on DHCPv4/DHCPv6 issues 3. Use an encoding to carry IPv4 addresses in the DHCPv6 option; for example, Vijay suggests: 3. Network Information Service (NIS) Servers Option The Network Information Service (NIS) Servers option provides a list of one or more IPv6 addresses of NIS servers available to the client. If any of the NIS servers is available with an IPv4 address, then its address will be represented in "IPv4-mapped IPv6 address" [RFC3513] format. Clients MUST treat the list of NIS servers as an ordered list. The server MAY list the NIS servers in the order of preference. For the DHCPv6 DNS servers option, the WG opted for alternative 1, which seems to me to be the right thing to do for the NIS servers option, as well. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 4 17:55:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05609; Wed, 4 Feb 2004 17:55: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 1AoVvD-0006sj-GN; Wed, 04 Feb 2004 17:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVue-0006s3-Rj for dhcwg@optimus.ietf.org; Wed, 04 Feb 2004 17:54: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 RAA05548 for ; Wed, 4 Feb 2004 17:54:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVuc-0003hO-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 17:54:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVtf-0003cb-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 17:53:28 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AoVsv-0003Y8-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 17:52:41 -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 3A3CA22DE7A; Wed, 4 Feb 2004 16:42:36 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> References: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) 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] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Date: Wed, 4 Feb 2004 16:52:41 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.612) 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 On Feb 4, 2004, at 4:16 PM, Ralph Droms wrote: > For the DHCPv6 DNS servers option, the WG opted for alternative 1, > which > seems to me to be the right thing to do for the NIS servers option, as > well. That seems right. There is no need for additional complexity here. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 4 19:52:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11419; Wed, 4 Feb 2004 19:52: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 1AoXkP-0004GQ-PY; Wed, 04 Feb 2004 19:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoXk9-0004GC-Lm for dhcwg@optimus.ietf.org; Wed, 04 Feb 2004 19:51:45 -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 TAA11404 for ; Wed, 4 Feb 2004 19:51:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoXk7-0000KU-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 19:51:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoXj4-0000EP-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 19:50:39 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AoXiL-00008R-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 19:49:53 -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 i150neGn010634; Wed, 4 Feb 2004 19:49:48 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" , "'Ralph Droms'" Cc: Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Date: Wed, 4 Feb 2004 19:49:50 -0500 Message-ID: <000501c3eb81$f94a98f0$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 Importance: Normal In-Reply-To: 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 agree as well. Alternative 1 is best. -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, February 04, 2004 5:53 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt On Feb 4, 2004, at 4:16 PM, Ralph Droms wrote: > For the DHCPv6 DNS servers option, the WG opted for alternative 1, > which > seems to me to be the right thing to do for the NIS servers option, as > well. That seems right. There is no need for additional complexity here. _______________________________________________ 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 Feb 5 04:59:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09321; Thu, 5 Feb 2004 04:59: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 1AogHn-0007Xr-6d; Thu, 05 Feb 2004 04:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AogHa-0007XM-Vd for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 04:58: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 EAA09313 for ; Thu, 5 Feb 2004 04:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AogHX-0002r3-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 04:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AogGc-0002m0-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 04:57:51 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AogFy-0002cL-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 04:57:10 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119571>; Thu, 5 Feb 2004 10:58:28 +0100 Received: by merkur with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Feb 2004 10:55:10 +0100 Message-ID: From: "Rentschler, Markus" To: Mark Stapp , dhcwg@ietf.org Subject: AW: [dhcwg] vendor-specific relay suboption draft Date: Thu, 5 Feb 2004 10:55:10 +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 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 Mark, This is a useful thing. I support it. Markus > -----Urspr=FCngliche Nachricht----- > Von: Mark Stapp [SMTP:mjs@cisco.com] > Gesendet am: Mittwoch, 4. Februar 2004 18:25 > An: dhcwg@ietf.org > Betreff: [dhcwg] vendor-specific relay suboption draft >=20 > Vendor-specific capabilities seem to me to be a useful addition to = the=20 > relay information data, so I've published (as an individual = submission) a=20 > draft defining a vendor-specific relay suboption. I liked and have = re-used >=20 > the self-identifying method that Josh used in his vendor-identifying=20 > vendor-specific option drafts. >=20 > I'd like to ask the WG to consider adopting this draft as a WG item. >=20 > Here's a link to the initial version; please take a look and offer > feedback. >=20 > = http://www.ietf.org/internet-drafts/draft-stapp-dhc-vendor-suboption-00.= tx > t >=20 > Thanks, > Mark >=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 Feb 5 15:48:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05742; Thu, 5 Feb 2004 15:48: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 1AoqPp-00071O-JF; Thu, 05 Feb 2004 15: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 1AoqOs-0006y7-0m for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 15:47:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05618; Thu, 5 Feb 2004 15:46:59 -0500 (EST) Message-Id: <200402052046.PAA05618@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, 05 Feb 2004 15:46:59 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vendor-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Vendor-Identifying Vendor Options for DHCPv4 Author(s) : J. Littlefield Filename : draft-ietf-dhc-vendor-01.txt Pages : 9 Date : 2004-2-5 The DHCP options for Vendor Class and Vendor-Specific Information can be ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, which contain Enterprise Numbers to remove ambiguity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vendor-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-vendor-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-vendor-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-5161152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vendor-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vendor-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-5161152.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 Feb 5 17:45:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17143; Thu, 5 Feb 2004 17:45: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 1AosF5-0001W3-4J; Thu, 05 Feb 2004 17: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 1AosEK-0001KR-KI for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 17:44: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 RAA17101 for ; Thu, 5 Feb 2004 17:44:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AosEI-0003Cw-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 17:44:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AosDM-0003B5-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 17:43:17 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AosCp-00038u-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 17:42:43 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 05 Feb 2004 14:41:33 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i15Mg9YQ027635 for ; Thu, 5 Feb 2004 17:42:11 -0500 (EST) Received: from cisco.com ([128.107.168.175]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFV91382; Thu, 5 Feb 2004 17:42:09 -0500 (EST) Message-ID: <4022C6BD.4010201@cisco.com> Date: Thu, 05 Feb 2004 17:42:05 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: 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] new vendor-identifying vendor options 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: , Content-Transfer-Encoding: 7bit A new version of the vendor-identifying vendor options draft (draft-ietf-dhc-vendor-01.txt) is now available. There were a few glaring errors which have been corrected (such as borrowing too much from the DHCPv6 version of vendor-options, including 16-bit option codes and lengths). I've also addressed the issue that Ted brought up in Minneapolis as to a conflict with RFC 3396. As you know (and as I now know), RFC 3396 says that multiple instances of the same option must be concatenated into a single large value. This is to support large options and to work around the 256 octet limit for option sizes. Since the two new options I'm proposing are intended to occur multiple times with different values, I had to re-work the format to support concatenation. This adds another length octet into the option data. While this isn't the prettiest format, it solves the problem of RFC 3396 compatibility without attempting to make these options some sort of special case. Please give this short Internet-Draft a glance, and respond with comments and suggestions. Thanks, Josh Littlefield -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 5 18:47:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19668; Thu, 5 Feb 2004 18:47:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotC5-0001vU-MQ; Thu, 05 Feb 2004 18: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 1AotBP-0001u7-Kc for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 18:45: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 SAA19621 for ; Thu, 5 Feb 2004 18:45:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AotBM-000579-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 18:45:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotAU-00055q-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 18:44:23 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Aot9s-000527-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 18:43:44 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2004 15:42:28 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i15NhDYO007792 for ; Thu, 5 Feb 2004 18:43:13 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFV95726; Thu, 5 Feb 2004 18:43:12 -0500 (EST) Message-Id: <4.3.2.7.2.20040205183212.01e71a50@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Feb 2004 18:43:09 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.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: , PacketFront has issued a modified IPR statement about draft-ietf-dhc-subscriber-id-X.txt (publication on http://www.ietf.org/ipr.html is pending): PacketFront Sweden AB would like to update its IPR notification from April 17, 2003. The document draft-ietf-dhc-subscriber-id-X.txt describes technology or solutions for which PacketFront has related patents or patent applications pending. If a document based on this draft becomes an IETF standard PacketFront is prepared to license, on reasonable and non-discriminatory terms, any related PacketFront patents to the extent required to comply with the standard. Sweden AB Mats E. Jonsson Deputy CEO This new IPR statement is compatible with the text in section 10.3.2(C) of RFC 2026, and with similar IPRs on other IETF documents. Are there any objections now to resuming consideration of draft-ietf-dhc-subscriber-id-05.txt as a Proposed Standard? - RAlph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 5 18:52:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19829; Thu, 5 Feb 2004 18:52: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 1AotHt-0002E3-CC; Thu, 05 Feb 2004 18:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotHA-0002BE-2r for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 18:51: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 SAA19791 for ; Thu, 5 Feb 2004 18:51:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AotH6-0005JY-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 18:51:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotG8-0005H0-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 18:50:13 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AotFB-0005Dh-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 18:49:13 -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 <0HSM00B12Y57F3@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 06 Feb 2004 08:48:43 +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 <0HSM00H27Y4S32@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 06 Feb 2004 08:48:29 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HSM0090PY4SUP@mmp1.samsung.com> for dhcwg@ietf.org; Fri, 06 Feb 2004 08:48:28 +0900 (KST) Date: Fri, 06 Feb 2004 08:47:30 +0900 From: "S. Daniel Park" To: dhcwg@ietf.org Cc: soohong.park@samsung.com Message-id: <00f701c3ec42$8a50e5a0$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/mixed; boundary="Boundary_(ID_2QLLs+onEuL4oN/QAc6FpQ)" 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 Subject: [dhcwg] [New I-D] DHCP Option for Configuring IPv6-in-IPv4 Tunnels 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_2QLLs+onEuL4oN/QAc6FpQ) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-00.txt A new draft of DHCP Option for Configuring IPv6-in-IPv4 Tunnels is now available. This draft aims to provide an efficient IPv6 connectivity through IPv6-over-IPv4 tunnel services from dual stack hosts. Comments are welcome ! Daniel --Boundary_(ID_2QLLs+onEuL4oN/QAc6FpQ) Content-type: Message/External-body; name=ATT00078.dat Content-disposition: attachment; filename=ATT00078.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-5155016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daniel-dhc-ipv6in4-opt-00.txt --Boundary_(ID_2QLLs+onEuL4oN/QAc6FpQ) Content-type: Message/External-body; name=draft-daniel-dhc-ipv6in4-opt-00.txt Content-disposition: attachment; filename=draft-daniel-dhc-ipv6in4-opt-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-5155016.I-D@ietf.org> --Boundary_(ID_2QLLs+onEuL4oN/QAc6FpQ)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 5 19:02:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20225; Thu, 5 Feb 2004 19:02: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 1AotRa-0002ul-52; Thu, 05 Feb 2004 19:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotQv-0002tY-B4 for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 19:01: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 TAA20165 for ; Thu, 5 Feb 2004 19:01:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AotQs-0005jr-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:01:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotQ1-0005hn-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:00:25 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AotPj-0005f3-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:00:07 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EEC461BD9; Fri, 6 Feb 2004 00:59:36 +0100 (CET) Date: Thu, 05 Feb 2004 15:59:30 -0800 From: Harald Tveit Alvestrand To: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <2108571886.1075996769@halvestr-w2k1> In-Reply-To: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> References: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========856ED016C767D07140A7==========" 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 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: , --==========856ED016C767D07140A7========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (hi - just visiting) just to be perfectly clear..... as an occasional network configurer, I think it seems like a pain in the=20 backside to have to configure two separate configuration tools that speak=20 two separate configuration protocols in order to get two pieces of config=20 info (the ipv4 address and the ipv6 address) to a single application on a=20 network client. and as an applications programmer, I think it's a pain in the posterior to=20 have to make two unrelated queries and get two unrelated responses back,=20 and having to use local configuration, tea leaves, chicken entrails or=20 scientific wild-assed guessing to figure out how to combine them, just=20 becaue my client software runs on a dual-stack host. but that's the WG's choice - you can call that either way, and I'll be=20 happy to remove my comment on the documents. But as long as you don't say one way or the other that I'll have to do that = or that I don't have to do that, the spec is incomplete - I don't know what = to implement. And that's why I've called the question. Harald --On 4. februar 2004 17:16 -0500 Ralph Droms wrote: > The IESG has one remaining comment on this draft (see > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dprint_ballot&b > allot_id=3D896&filename=3Ddraft-ietf-dhc-dhcpv6-opt-nisconfig): > > what does a DHCPv6 server do when it wants to indicate that there's a > NIS > server available with an IPv4 address and another NIS server available > with > an IPv6 address? > > The two reasons why this can be a silly question: > > - NIS wouldn't work with such a config, so all the servers' addresses > obviously have to be one address type > - You can always encode a v4 address as a v6 address using the > 96-zeroes > convention (or something else), so it's obvious how to do it > > But I think the document should address the issue. > > We have a couple of alternatives to addressing the issue: > > 1. Reserve DHCPv6 for IPv6 NIS servers and DHCPv4 for IPv4 NIS servers > 2. Wait until the WG completes its work on DHCPv4/DHCPv6 issues > 3. Use an encoding to carry IPv4 addresses in the DHCPv6 option; for > example, Vijay suggests: > > 3. Network Information Service (NIS) Servers Option > > The Network Information Service (NIS) Servers option provides a > list of one or more IPv6 addresses of NIS servers available to the > client. If any of the NIS servers is available with an IPv4 > address, > then its address will be represented in "IPv4-mapped IPv6 address" > [RFC3513] > format. Clients MUST treat the list of NIS servers as an ordered > list. The server MAY list the NIS servers in the order of > preference. > > For the DHCPv6 DNS servers option, the WG opted for alternative 1, which > seems to me to be the right thing to do for the NIS servers option, as > well. > > - Ralph > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > --==========856ED016C767D07140A7========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFAItjmOMj+2+WY0F4RAsRXAKC3aVJwW51To4gcaL1QLbfDDWjjLwCfRXhx 1rSKEG6fkmlvwk3dOxS1EFc= =jQt5 -----END PGP SIGNATURE----- --==========856ED016C767D07140A7==========-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 5 19:13:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20473; Thu, 5 Feb 2004 19:13: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 1AotcA-0003g0-H5; Thu, 05 Feb 2004 19:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotbY-0003fB-B4 for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 19:12:20 -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 TAA20464 for ; Thu, 5 Feb 2004 19:12:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AotbW-00064G-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:12:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotaU-00062Z-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:11:15 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AotZd-00061a-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:10:22 -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 A468D1B22C7; Thu, 5 Feb 2004 17:59:56 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040205183212.01e71a50@flask.cisco.com> References: <4.3.2.7.2.20040205183212.01e71a50@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) 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] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 5 Feb 2004 18:10:14 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.612) 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 On Feb 5, 2004, at 5:43 PM, Ralph Droms wrote: > If a document based on this draft becomes an IETF standard > PacketFront is > prepared to license, on reasonable and non-discriminatory terms, > any > related PacketFront patents to the extent required to comply with > the standard. > This new IPR statement is compatible with the text in section 10.3.2(C) > of RFC 2026, and with similar IPRs on other IETF documents. Are there > any objections now to resuming consideration of > draft-ietf-dhc-subscriber-id-05.txt as a Proposed Standard? Yes. I object, unless PacketFront states that they are willing to license this for free to people who agree to cross-license. This functionality doesn't deserve a patent, and isn't useful enough to merit advancing since it is encumbered by patent applications. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 5 19:25:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20711; Thu, 5 Feb 2004 19:25: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 1Aotnq-0003y4-Mq; Thu, 05 Feb 2004 19:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aotn7-0003wP-N9 for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 19:24: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 TAA20668 for ; Thu, 5 Feb 2004 19:24:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aotn6-0006Ok-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:24:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotmB-0006N7-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:23:20 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AotlR-0006LT-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 19:22: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 DDEC02A9C59; Thu, 5 Feb 2004 18:12:16 -0600 (CST) In-Reply-To: <2108571886.1075996769@halvestr-w2k1> References: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> <2108571886.1075996769@halvestr-w2k1> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8FE9A5B1-583A-11D8-A6E8-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Date: Thu, 5 Feb 2004 18:22:35 -0600 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.612) 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 On Feb 5, 2004, at 5:59 PM, Harald Tveit Alvestrand wrote: > as an occasional network configurer, I think it seems like a pain in > the backside to have to configure two separate configuration tools > that speak two separate configuration protocols in order to get two > pieces of config info (the ipv4 address and the ipv6 address) to a > single application on a network client. > > and as an applications programmer, I think it's a pain in the > posterior to have to make two unrelated queries and get two unrelated > responses back, and having to use local configuration, tea leaves, > chicken entrails or scientific wild-assed guessing to figure out how > to combine them, just becaue my client software runs on a dual-stack > host. You are totally right. This sucks. The problem is that the alternative is even worse. This isn't even strictly an IPv4/IPv6 issue - consider what happens when you have two network interfaces that are configured by two different servers in two different administrative domains! Unfortunately, we haven't been able to think of a way to specify how DHCP devices should deal with this problem. It's easy to specify a scenario, and then say what should be done in that scenario, but it's hard to specify a set of rules that will work in all scenarios. Anyway, you have to support both protocols, because you might be on an IPv4-only or IPv6-only network, so even if we specified a way to configure your IPv4 stack with DHCPv6, you'd still have to implement a DHCPv4 client. :'( It's possible that when we have some real-world experience with this, we might have enough information to make a stab at specifying a general solution to this problem, but I don't think we do right now, and if we tried, we'd wind up in ten-years-later land. If you have an idea for a general solution, we'd all like to hear it, by the way. But please remember that we're not complete dummies, and try to think about six chess moves ahead rather than just stating an obvious, but wrong, idea, because we've probably already considered and discarded that idea. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 5 22:50:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26451; Thu, 5 Feb 2004 22:50: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 1Aox0F-0000JY-DJ; Thu, 05 Feb 2004 22: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 1Aowzf-0000Hj-M3 for dhcwg@optimus.ietf.org; Thu, 05 Feb 2004 22:49: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 WAA26446 for ; Thu, 5 Feb 2004 22:49:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aowzc-0007Nd-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 22:49:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aowyh-0007M5-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 22:48:28 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AowyW-0007K7-00 for dhcwg@ietf.org; Thu, 05 Feb 2004 22:48:16 -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 i163m257074769; Thu, 5 Feb 2004 22:48:10 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" , "'Ralph Droms'" Cc: Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 5 Feb 2004 22:48:03 -0500 Message-ID: <001301c3ec64$093fb280$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: 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 I'm inclined to agree with Ted, but I have no idea how strong a need = exists for this capability. If the need is strong, people will do it anyway (perhaps using an "unassigned" relay-agent suboption) and they'll have = to deal with the patent issues anyway (or perhaps be exposed without = knowing about potential issues before forging ahead). So, if there is a strong need for this, I'd prefer we move forward with = it and just make sure that there is a clear indication in the RFC that this = MAY be covered by one or more patents (either now or in the future). See RFC 2026 10.3.2(C): "The IESG may also direct that a summary of the results = be included in any RFC published containing the specification." So, that leaves the issue as to whether there is a strong need for this suboption. I personally don't. - Bernie=20 -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted Lemon Sent: Thursday, February 05, 2004 7:10 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt On Feb 5, 2004, at 5:43 PM, Ralph Droms wrote: > If a document based on this draft becomes an IETF standard=20 > PacketFront is > prepared to license, on reasonable and non-discriminatory terms,=20 > any > related PacketFront patents to the extent required to comply with > the standard. > This new IPR statement is compatible with the text in section = 10.3.2(C) > of RFC 2026, and with similar IPRs on other IETF documents. Are there > any objections now to resuming consideration of > draft-ietf-dhc-subscriber-id-05.txt as a Proposed Standard? Yes. I object, unless PacketFront states that they are willing to=20 license this for free to people who agree to cross-license. This=20 functionality doesn't deserve a patent, and isn't useful enough to=20 merit advancing since it is encumbered by patent applications. _______________________________________________ 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 Feb 6 05:48:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19919; Fri, 6 Feb 2004 05:48: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 1Ap3Wj-0001Rv-Cp; Fri, 06 Feb 2004 05: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 1Ap3WO-0001RX-HO for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 05:47: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 FAA19883 for ; Fri, 6 Feb 2004 05:47:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3WK-0002gV-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 05:47:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap3VQ-0002dw-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 05:46:41 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3V3-0002bL-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 05:46:17 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i16Ak9f17845; Fri, 6 Feb 2004 17:46:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i16Agk916192; Fri, 6 Feb 2004 17:42:46 +0700 (ICT) From: Robert Elz To: Harald Tveit Alvestrand cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt In-Reply-To: <2108571886.1075996769@halvestr-w2k1> References: <2108571886.1075996769@halvestr-w2k1> <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Feb 2004 17:42:46 +0700 Message-ID: <15011.1076064166@munnari.OZ.AU> 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Thu, 05 Feb 2004 15:59:30 -0800 From: Harald Tveit Alvestrand Message-ID: <2108571886.1075996769@halvestr-w2k1> | as an occasional network configurer, I think it seems like a pain in the | backside to have to configure two separate configuration tools that speak | two separate configuration protocols in order to get two pieces of config | info (the ipv4 address and the ipv6 address) to a single application on a | network client. Yes, but do remember that all this is intended to just be a transitional artifact - a few years from now (well, perhaps a lot of years from now) IPv4 should be gone, it would be absurd in the extreme for DHCP (the DHCPv6 name variant probably long forgotten) to be handing back long dead address formats - or even to be capable of it. The suggested solution to the issue raised is really not just the easy one, it is also the only one that makes much sense. If I were a node, making a v6 DHCP query, and the answer I got back told me that to use NIS I should use this v4 address, I'd be astounded. How do I do that? I have no v4 address, I can't talk v4 at all, and yet DHCP is telling me to use a v4 address to communicate with NIS? Absurd. If there is only v4 NIS, then as far as a v6 node is concerned, there is no NIS. And not supplying any NIS information in the DHCP offer is the right thing to do, not just to fill in some random address from some random protocol and hope that the client happens to know how to deal with it. If there is both v6 and v4 information available, and the node is dual stack, then it is being configured in both stacks - each configuration will configure its own access to the servers (v6 v6 access, and v4 v4 access). That's exactly as it should be. That way everyone gets (as mush as is available) exactly what they want. How the dual stack node decides which to use is up to it (in 99% of cases for this particular information, it will make no difference at all). Having to deal with both v4 and v6 at the minute is a nuisance - but the solution to this isn't to make every other protocol aware that both exist in parallel, and add lots of mechanism to every place else to allow use preferences to be stated, it is to make v4 go away, completely, as soon as possible, so we're back with only needing to deal with one set of information again. kre ps: somewhere, in the DHCPv6 docs, if it isn't already stated, it should be, that DHCPv6 returns only v6 (and protocol neutral) information, no v4 noise at all, anywhere, ever, in any format. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 08:32:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25531; Fri, 6 Feb 2004 08:32: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 1Ap65R-0005aw-Lu; Fri, 06 Feb 2004 08:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap65F-0005aQ-NF for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 08:31: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 IAA25524 for ; Fri, 6 Feb 2004 08:31:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap65E-0004uf-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 08:31:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap64P-0004rq-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 08:30:58 -0500 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1Ap63r-0004lF-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 08:30:23 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i16DTetv512332; Fri, 6 Feb 2004 08:29:40 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-143-48.mts.ibm.com [9.49.143.48]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i16DTd0L137420; Fri, 6 Feb 2004 06:29:39 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i16DT0r11498; Fri, 6 Feb 2004 08:29:01 -0500 Message-Id: <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> To: Ted Lemon cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt In-Reply-To: Message from mellon@fugue.com of "Thu, 05 Feb 2004 18:10:14 CST." Date: Fri, 06 Feb 2004 08:29:00 -0500 From: Thomas Narten 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 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 Ted. > On Feb 5, 2004, at 5:43 PM, Ralph Droms wrote: > > If a document based on this draft becomes an IETF standard > > PacketFront is > > prepared to license, on reasonable and non-discriminatory terms, > > any > > related PacketFront patents to the extent required to comply with > > the standard. > > This new IPR statement is compatible with the text in section 10.3.2(C) > > of RFC 2026, and with similar IPRs on other IETF documents. Are there > > any objections now to resuming consideration of > > draft-ietf-dhc-subscriber-id-05.txt as a Proposed Standard? > Yes. I object, unless PacketFront states that they are willing to > license this for free to people who agree to cross-license. This > functionality doesn't deserve a patent, and isn't useful enough to > merit advancing since it is encumbered by patent applications. Note: each WG member needs to decide for themselves whether or not to support advancement of this spec based on whatever concerns (including IPR) they have. But I at least would like to understand why Ted (and others?) believe that the above terms should be required before advancing this document, when other DHC documents also with IPR terms that are not "free" have apparently not raised a similar concern. That is, what are the issues that make this case different than others? I think it would be good to understand what the general criteria would be, as the issue will likely come up again in the future (that is unfortunately the reality). E.g., see http://www.ietf.cnri.reston.va.us/ietf/IPR/cisco-ipr-draft-ietf-dhc-server-override.txt Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 09:57:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27573; Fri, 6 Feb 2004 09:57: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 1Ap7Pu-0002Gb-NI; Fri, 06 Feb 2004 09:57:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7Pa-00029g-EQ for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 09:56: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 JAA27447 for ; Fri, 6 Feb 2004 09:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7PY-0001ej-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 09:56:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7OM-0001OC-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 09:55:39 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7MH-00012x-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 09:53:29 -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 BC1A61B2288; Fri, 6 Feb 2004 08:43:00 -0600 (CST) In-Reply-To: <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> References: <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3727630C-58B4-11D8-A6E8-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Ralph Droms From: Ted Lemon Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Fri, 6 Feb 2004 08:53:25 -0600 To: Thomas Narten X-Mailer: Apple Mail (2.612) 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 On Feb 6, 2004, at 7:29 AM, Thomas Narten wrote: > But I at least would like to understand why Ted (and others?) believe > that the above terms should be required before advancing this > document, when other DHC documents also with IPR terms that are not > "free" have apparently not raised a similar concern. The Motorola patent on the relay agent information option has the IPR terms I am asking for. The reason it has those terms is because I raised a big fuss when Motorola announced that they'd patented it, for the very obvious reason that I'd been involved in developing the RAIO and was upset that Motorola had patented my work. In the case of the Motorola patent on DHCP as a whole, whatever that is, the WG was never, as far as I can recall, notified that Motorola had made this claim. In the case of the Cisco patent on DHCP as a whole, again, the WG was never notified of this claim. Had the WG been notified of either of these claims, I can assure you that I would have kicked up a fuss. In this case, we have a patent on some very obvious technology that in no way merits a patent. We are being asked, as a group, to promote this technology. I am against promoting this technology if PacketFront's purpose in acquiring this patent is to charge people royalties under some definition of "reasonable." I am pushing back on this in hopes that PacketFront will clarify their intentions. I suspect that they acquired this patent for defensive reasons, and I have complete sympathy with that, but if that is the case, I want them to change the stated terms to reflect that. If I don't push back, PacketFront has no reason to change their terms, and this creates uncertainty for implementors of DHCP: will PacketFront sue me? Will their license terms meet *my* definition of reasonable? So I'm pushing back. I hope that PacketFront's intentions are as I suspect they are, and that as a result of this pushback they will clarify their license terms. If they do not, I am happy to just let the technology go unimplemented - I don't think it's that important. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 10:23:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00738; Fri, 6 Feb 2004 10:23: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 1Ap7os-0002No-8S; Fri, 06 Feb 2004 10:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7on-0002NG-IE for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 10:22: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 KAA00732 for ; Fri, 6 Feb 2004 10:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7ol-0004SM-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:22:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7np-0004Oy-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:21:58 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7nV-0004Lf-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:21:37 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i16FKuOH418094; Fri, 6 Feb 2004 10:20:56 -0500 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i16FKtbP110400; Fri, 6 Feb 2004 08:20:55 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i16FH9Io020314; Fri, 6 Feb 2004 10:17:09 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i16FH8pP020309; Fri, 6 Feb 2004 10:17:08 -0500 Message-Id: <200402061517.i16FH8pP020309@rotala.raleigh.ibm.com> To: Ted Lemon cc: dhcwg@ietf.org, Ralph Droms Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt In-Reply-To: Message from mellon@fugue.com of "Fri, 06 Feb 2004 08:53:25 CST." <3727630C-58B4-11D8-A6E8-000A95D9C74C@fugue.com> Date: Fri, 06 Feb 2004 10:17:08 -0500 From: Thomas Narten 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ted, Thanks for the explanation. Some more questions. > In the case of the Motorola patent on DHCP as a whole, whatever that > is, the WG was never, as far as I can recall, notified that Motorola > had made this claim. In the case of the Cisco patent on DHCP as a > whole, again, the WG was never notified of this claim. Had the WG > been notified of either of these claims, I can assure you that I would > have kicked up a fuss. Right. Neither I (nor Ralph apparently) knew about it. That's unfortunate, but may also have to do with failed (or lacking) internal processes that would have ensured that the WG be notified whenever an IPR statement is posted on the web site. That is being followed up separately. > In this case, we have a patent on some very obvious technology that in > no way merits a patent. We are being asked, as a group, to promote > this technology. I am against promoting this technology if > PacketFront's purpose in acquiring this patent is to charge people > royalties under some definition of "reasonable." I am pushing back on > this in hopes that PacketFront will clarify their intentions. I > suspect that they acquired this patent for defensive reasons, and I > have complete sympathy with that, but if that is the case, I want them > to change the stated terms to reflect that. If I don't push back, > PacketFront has no reason to change their terms, and this creates > uncertainty for implementors of DHCP: will PacketFront sue me? Will > their license terms meet *my* definition of reasonable? Understood. But one thing that I'm also trying to understand, is that Cisco also has IPR on some other drafts, but has not stated that they will license for free. (At least that is my understanding. I'm sure someone will correct me if I have that wrong.) E.g., see draft-ietf-dhc-agentopt-radius-03.txt, a document the WG has recommended advancement of. I think it would be helpful to understand how the situation differs in this case. > So I'm pushing back. I hope that PacketFront's intentions are as I > suspect they are, and that as a result of this pushback they will > clarify their license terms. If they do not, I am happy to just let > the technology go unimplemented - I don't think it's that important. That is certainly a position you (and the WG as a whole - if this is the direction it wants to go in) is free to take. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 10:28:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01113; Fri, 6 Feb 2004 10:28: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 1Ap7th-0002dB-5l; Fri, 06 Feb 2004 10: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 1Ap7tW-0002ck-IO for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 10:27: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 KAA01108 for ; Fri, 6 Feb 2004 10:27:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7tU-0004jx-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:27:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7sc-0004hP-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:26: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 1Ap7sQ-0004eQ-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:26:42 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Feb 2004 07:33:27 +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 i16FQ99T011043 for ; Fri, 6 Feb 2004 07:26:10 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFW30849; Fri, 6 Feb 2004 10:26:08 -0500 (EST) Message-Id: <4.3.2.7.2.20040206101524.01ec8cc0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 10:25:57 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt In-Reply-To: <3727630C-58B4-11D8-A6E8-000A95D9C74C@fugue.com> References: <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> 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.0 required=5.0 tests=AWL 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: , For completeness and to correct inaccuracies in previous messages in this thread about IPR statements relative to DHCP, here is the complete lists of published IPR statements, from http://www.ietf.org/ipr.html, as returned by a search on "dhcp" through the IETF Search Engine, http://search.ietf.org: http://www.ietf.org/ietf/IPR/MOTOROLA-DHCP http://www.ietf.org/ietf/IPR/MOTOROLA-DHCP-AGENT-OPTIONS http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-dhc-server-override.txt http://www.ietf.org/ietf/IPR/CISCO-8021X.txt http://www.ietf.org/ietf/IPR/CISCO-raj-dhc-subnet-alloc.txt http://www.ietf.org/ietf/IPR/PacketFront-IPR.txt (note that PacketFront has submitted a revised IPR statement about draft-ietf-dhc-subscriber-id-X.txt, which has not yet appeared on http://www.ietf.org/ipr.html) The MOTOROLA-DHCP-AGENT-OPTIONS IPR statement appears to be the only statement that includes the text: "royalty-free license to all parties implementing the draft, subject to reciprocity of the licensed party." The other statements (including the updated PacketFront statement but not the old PacketFront-IPR.txt) all include text similar to the text from section 10.3.1(C) of RFC 2026: "any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms." - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 10:48:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02027; Fri, 6 Feb 2004 10:48: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 1Ap8D2-0004OF-8Z; Fri, 06 Feb 2004 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8CI-0004H2-E6 for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 10:47: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 KAA01970 for ; Fri, 6 Feb 2004 10:47:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8CF-00061W-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:47:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8BS-0005vk-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:46:23 -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 1Ap8An-0005lv-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 10:45:41 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Feb 2004 07:52:25 +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 i16Fj8Gv026263; Fri, 6 Feb 2004 07:45:08 -0800 (PST) Received: from mjs-xp.cisco.com ([161.44.65.244]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFW32818; Fri, 6 Feb 2004 10:45:06 -0500 (EST) Message-Id: <4.3.2.7.2.20040206100828.01c46ee8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 10:44:40 -0500 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20040205183212.01e71a50@flask.cisco.com> 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.0 required=5.0 tests=none 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: , I'd like to speak up in favor of this draft. (That shouldn't be surprising, since I'm an author.) The technique described in the draft seems obvious and non-novel to me. I can't imagine that there is intellectual property there, and I'd be happy to offer my expert (well, enthusiastic amateur, at least) opinion about that to anyone who cares to ask. in DHCP, we've been shipping information that identifies clients around since forever, in the mac, client-id, host-name, fqdn, and so forth options. someone who thinks they've 'invented' that should think hard before going after anyone who uses such information in DHCP messages. The merits of the packetfront IP claims aside, I do believe that there will be users of relay information that is different from the remote-id and circuit-id, or who need information in addition to those suboptions. If a standard suboption isn't available, implementors will do just what Bernie Volz suggested: they'll pick random suboptions and use them. That seems much less desirable to me. We've usually tried, as a group, to allocate well-known option and suboption numbers with clearly described data for specific purposes. That improves the lives of implementors, vendors, and customers. I'd like to see us move forward and do the same here. years of history with some vendors' IPR practices have given us confidence that their policies are defensive, and we have been able to proceed with standardization that co-exists with intellectual property. we don't have any history with packetfront's IPR claims, unlike those of some other vendors. it would be nice if they'd make their intentions more clear. -- Mark At 06:43 PM 2/5/2004 -0500, Ralph Droms wrote: >PacketFront has issued a modified IPR statement about >draft-ietf-dhc-subscriber-id-X.txt (publication on >http://www.ietf.org/ipr.html is pending): > > PacketFront Sweden AB would like to update its IPR notification from > April 17, 2003. > > The document draft-ietf-dhc-subscriber-id-X.txt describes technology or > solutions for which PacketFront has related patents or patent > applications > pending. > > If a document based on this draft becomes an IETF standard PacketFront is > prepared to license, on reasonable and non-discriminatory terms, any > related PacketFront patents to the extent required to comply with > the standard. > > Sweden AB > > Mats E. Jonsson > > Deputy CEO > >This new IPR statement is compatible with the text in section 10.3.2(C) >of RFC 2026, and with similar IPRs on other IETF documents. Are there >any objections now to resuming consideration of >draft-ietf-dhc-subscriber-id-05.txt as a Proposed Standard? > >- RAlph > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 11:12:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02731; Fri, 6 Feb 2004 11:12: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 1Ap8aG-00062x-Qw; Fri, 06 Feb 2004 11:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8a6-00061j-32 for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 11:11: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 LAA02677 for ; Fri, 6 Feb 2004 11:11:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8a3-0007B4-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 11:11:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8ZA-000784-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 11:10:52 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8YQ-00075C-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 11:10:06 -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 4235213; Fri, 06 Feb 2004 17:10:01 +0100 From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: Ted Lemon Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Fri, 6 Feb 2004 17:24:59 +0100 User-Agent: KMail/1.5.4 References: <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <3727630C-58B4-11D8-A6E8-000A95D9C74C@fugue.com> In-Reply-To: <3727630C-58B4-11D8-A6E8-000A95D9C74C@fugue.com> Cc: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402061724.59611.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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday 06 February 2004 15:53, Ted Lemon wrote: > In this case, we have a patent on some very obvious technology that in > no way merits a patent. We are being asked, as a group, to promote > this technology. I am against promoting this technology if > PacketFront's purpose in acquiring this patent is to charge people > royalties under some definition of "reasonable." I am pushing back on > this in hopes that PacketFront will clarify their intentions. I > suspect that they acquired this patent for defensive reasons, and I > have complete sympathy with that, but if that is the case, I want them > to change the stated terms to reflect that. If I don't push back, > PacketFront has no reason to change their terms, and this creates > uncertainty for implementors of DHCP: will PacketFront sue me? Will > their license terms meet *my* definition of reasonable? I don't see why it's unreasonable to ask for IPR statements that guarantee royalty-free implementation with reciprocity, in return for promotion of the patented technology (as well as the expertise of this group). IMO, by not requiring a royalty-free implementation guarantee, we're outright inviting WG members to start patenting everything they can in order to get some kind of insurance against other patent holders. That's not the kind of environment I'd like to see this WG in. - 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 Fri Feb 6 12:49:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06919; Fri, 6 Feb 2004 12:49: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 1ApA69-0006BL-Pw; Fri, 06 Feb 2004 12:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApA60-0006B0-KN for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 12:48: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 MAA06907 for ; Fri, 6 Feb 2004 12:48:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApA5y-0006Nr-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 12:48:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApA52-0006L8-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 12:47:52 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1ApA4Y-0006Ie-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 12:47:22 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id E45871C026A6; Fri, 6 Feb 2004 12:47:19 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i16HPaZ04840; Fri, 6 Feb 2004 22:55:36 +0530 (IST) Message-ID: <4023D31C.5060206@india.hp.com> Date: Fri, 06 Feb 2004 23:17:08 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Cc: DHCPWG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt References: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; 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 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 Solution 1 seems more logical to me.. I support solution 1 Vijay Ralph Droms wrote: > The IESG has one remaining comment on this draft (see > https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=896&filename=draft-ietf-dhc-dhcpv6-opt-nisconfig): > > > what does a DHCPv6 server do when it wants to indicate that there's > a NIS > server available with an IPv4 address and another NIS server > available with > an IPv6 address? > > The two reasons why this can be a silly question: > > - NIS wouldn't work with such a config, so all the servers' addresses > obviously have to be one address type > - You can always encode a v4 address as a v6 address using the > 96-zeroes > convention (or something else), so it's obvious how to do it > > But I think the document should address the issue. > > We have a couple of alternatives to addressing the issue: > > 1. Reserve DHCPv6 for IPv6 NIS servers and DHCPv4 for IPv4 NIS servers > 2. Wait until the WG completes its work on DHCPv4/DHCPv6 issues > 3. Use an encoding to carry IPv4 addresses in the DHCPv6 option; for > example, Vijay suggests: > > 3. Network Information Service (NIS) Servers Option > > The Network Information Service (NIS) Servers option provides a > list of one or more IPv6 addresses of NIS servers available to the > client. If any of the NIS servers is available with an IPv4 > address, > then its address will be represented in "IPv4-mapped IPv6 > address" [RFC3513] > format. Clients MUST treat the list of NIS servers as an ordered > list. The server MAY list the NIS servers in the order of > preference. > > For the DHCPv6 DNS servers option, the WG opted for alternative 1, which > seems to me to be the right thing to do for the NIS servers option, as > well. > > - Ralph > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 13:46:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08960; Fri, 6 Feb 2004 13: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 1ApAzJ-0002NZ-J6; Fri, 06 Feb 2004 13: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 1ApAzA-0002Ms-3U for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 13:45: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 NAA08954 for ; Fri, 6 Feb 2004 13:45:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApAz7-0002J8-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 13:45:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApAyG-0002GS-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 13:44:56 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ApAxO-0002Dh-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 13:44:02 -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 23FFE1B3AD2; Fri, 6 Feb 2004 12:32:42 -0600 (CST) In-Reply-To: <200402061517.i16FH8pP020309@rotala.raleigh.ibm.com> References: <200402061517.i16FH8pP020309@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <42FF6BAC-58D4-11D8-A6E8-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Fri, 6 Feb 2004 12:42:48 -0600 To: Thomas Narten X-Mailer: Apple Mail (2.612) 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 On Feb 6, 2004, at 9:17 AM, Thomas Narten wrote: > Understood. But one thing that I'm also trying to understand, is that > Cisco also has IPR on some other drafts, but has not stated that they > will license for free. (At least that is my understanding. I'm sure > someone will correct me if I have that wrong.) E.g., see > draft-ietf-dhc-agentopt-radius-03.txt, a document the WG has > recommended advancement of. I think it would be helpful to understand > how the situation differs in this case. I don't think the situation is any different. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 14:21:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10851; Fri, 6 Feb 2004 14:21: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 1ApBXA-000518-6C; Fri, 06 Feb 2004 14:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBX8-00050s-KR for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 14:20:58 -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 OAA10839 for ; Fri, 6 Feb 2004 14:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBX6-000524-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 14:20:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBW8-0004yt-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 14:19:57 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ApBVi-0004vo-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 14:19:30 -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 D5B661B2282 for ; Fri, 6 Feb 2004 13:09:05 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <42FF6BAC-58D4-11D8-A6E8-000A95D9C74C@fugue.com> References: <200402061517.i16FH8pP020309@rotala.raleigh.ibm.com> <42FF6BAC-58D4-11D8-A6E8-000A95D9C74C@fugue.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65244DBE-58D9-11D8-A6E8-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Fri, 6 Feb 2004 13:19:33 -0600 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.612) 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 On Feb 6, 2004, at 12:42 PM, Ted Lemon wrote: > I don't think the situation is any different. To clarify, I don't think that there should be a double standard where we hassle PacketFront and Motorola about their IPR terms and don't hassle Cisco. I think that Cisco should be held to the same standard. Are any of the drafts about which Cisco has made IPR claims currently in last call? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 15:39:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14866; Fri, 6 Feb 2004 15:39: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 1ApCke-000587-FT; Fri, 06 Feb 2004 15:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCkd-00057Q-6H for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 15:38: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 PAA14861 for ; Fri, 6 Feb 2004 15:38:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCkb-00029X-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 15:38:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCjf-00026v-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 15:38:00 -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 1ApCjH-00024N-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 15:37:35 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Feb 2004 12:44:23 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i16Kb3T5024995; Fri, 6 Feb 2004 12:37:03 -0800 (PST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-16.cisco.com [10.82.240.16]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA11463; Fri, 6 Feb 2004 12:37:01 -0800 (PST) Message-Id: <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 15:36:59 -0500 To: Ted Lemon From: John Schnizlein Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Cc: Thomas Narten , dhcwg@ietf.org In-Reply-To: <3727630C-58B4-11D8-A6E8-000A95D9C74C@fugue.com> References: <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA14862 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 Clarification of some mis-information on this subject, and a few question= s: At 09:53 AM 2/6/2004, Ted Lemon wrote: >The Motorola patent on the relay agent information option has the IPR te= rms I am asking for. The reason it has those terms is because I raised = a big fuss when Motorola announced that they'd patented it, for the very = obvious reason that I'd been involved in developing the RAIO and was upse= t that Motorola had patented my work. Let us not forget that this stipulation of royalty-free is unusual. Most IPR statements claim only the typical RAND statement. What is the reason for suddenly requiring the unusual IPR statement in DH= C? >In the case of the Motorola patent on DHCP as a whole, whatever that is,= =20 Following the link Ralph posted, the Motorola-DHCP statement=20 includes the usual RAND: http://www.ietf.org/ietf/IPR/MOTOROLA-DHCP The message was received February 2, 2001 From: "Bawel, Paul (HT-EX)" Motorola, Inc. has applied for one or more patents relating to the=20 DHCP. In accordance with the intellectual property rights provisions=20 of the IETF Standards process, Motorola hereby affirms that it is=20 willing to make non-exclusive licenses available under fair, reasonable= =20 and non-discriminatory terms with respect to any patent it may be=20 awarded on technology related to the DHCP for parties implementing this= =20 standard. In Motorola =91s view, such terms would include availability= =20 of reciprocal licenses to Motorola, termination of licenses for related= =20 lawsuits, etc. >the WG was never, as far as I can recall, notified that Motorola had mad= e this claim. In the case of the Cisco patent on DHCP as a whole, again= , the WG was never notified of this claim. =20 There is no such claim as far as I can tell.=20 What is the basis of your assertion? What is the purpose of this assertion? > Had the WG been notified of either of these claims, I can assure you th= at I would have kicked up a fuss. > >In this case, we have a patent on some very obvious technology that in n= o way merits a patent. We are being asked, as a group, to promote this = technology. =20 Several aspects of the claim on subscriber-id are unusual: http://www.ietf.org/ietf/IPR/PacketFront-IPR.txt 1) the claim was by a company unrelated to the authors, who stated: "This document is the result of work done within Cisco Systems." 2) the claim was filed well after the draft was published 3) while the claim failed to include RAND language, it was later amended to include this usual statement Do you want to empower a company unrelated to the authors to block progress on a specification simply by filing a subjunctive statement: "that we may obtain intellectual property rights" > I am against promoting this technology if PacketFront's purpose in acqu= iring this patent is to charge people royalties under some definition of = "reasonable." I am pushing back on this in hopes that PacketFront will c= larify their intentions. I suspect that they acquired this patent for d= efensive reasons, and I have complete sympathy with that, but if that is = the case, I want them to change the stated terms to reflect that.=20 At 02:19 PM 2/6/2004, Ted Lemon wrote: >To clarify, I don't think that there should be a double standard where w= e hassle PacketFront and Motorola about their IPR terms and don't hassle = Cisco. I think that Cisco should be held to the same standard. Are an= y of the drafts about which Cisco has made IPR claims currently in last c= all? I agree that Cisco should be held to the same standard as typical=20 for a long time in DHC, and still typical elsewhere. That is RAND. My impression was that PacketFront changed their statement to=20 include RAND, which was not a matter of hassling them. Why is the IPR surprise and repair from PacketFront considered a reason to demand a new, unusual standard of zero-royalty from Cisco? Why is Thomas Narten associating the unusual PacketFront episode with the usual RAND which Cisco filed on the agentopt-radius document? Note that there was no surprise in that filing since the original draft draft-droms-agentopt-8021x-00.txt in Nov 2001 included a RAND=20 statement with a not-subjunctive patent declaration. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 15:42:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15182; Fri, 6 Feb 2004 15:42: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 1ApCnY-0005LD-LH; Fri, 06 Feb 2004 15:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCn2-0005Jl-AM for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 15:41: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 PAA14973; Fri, 6 Feb 2004 15:41:25 -0500 (EST) Message-Id: <200402062041.PAA14973@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 06 Feb 2004 15:41:24 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-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 : The Authentication Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, T. Lemon, R. Droms Filename : draft-ietf-dhc-auth-suboption-03.txt Pages : 15 Date : 2004-2-6 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option which supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in its payload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-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-auth-suboption-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-auth-suboption-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: <2004-2-6155550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-suboption-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-suboption-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-6155550.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 15:53:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16251; Fri, 6 Feb 2004 15:53: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 1ApCyD-0006dM-52; Fri, 06 Feb 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCy9-0006bS-9C for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 15:52: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 PAA16227 for ; Fri, 6 Feb 2004 15:52:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCy7-00038H-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 15:52:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCxB-00035M-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 15:51:58 -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 1ApCwY-0002zP-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 15:51:18 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2004 12:57:25 +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 i16Koj9T024087 for ; Fri, 6 Feb 2004 12:50:46 -0800 (PST) Received: from mjs-xp.cisco.com ([161.44.65.244]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFW65995; Fri, 6 Feb 2004 15:50:44 -0500 (EST) Message-Id: <4.3.2.7.2.20040206154534.02326130@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 15:50:26 -0500 To: dhcwg@ietf.org From: Mark Stapp Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-03.txt In-Reply-To: <200402062041.PAA14973@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.0 required=5.0 tests=none 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: , I've made a few small changes in this revision: I updated Ted's email address, and my office phone number. More importantly, Ralph has worked with the IESG to clarify the relationship between the relay authentication suboption draft and the relay-authentication-by-IPSEC draft. We've each added a paragraph to our 'Security Considerations' sections identifying the two drafts, and discussing briefly why we're offering two alternatives. -- Mark At 03:41 PM 2/6/2004 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Dynamic Host Configuration Working Group >of the IETF. > > Title : The Authentication Suboption for the DHCP Relay > Agent Option > Author(s) : M. Stapp, T. Lemon, R. Droms > Filename : draft-ietf-dhc-auth-suboption-03.txt > Pages : 15 > Date : 2004-2-6 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 16:11:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16870; Fri, 6 Feb 2004 16:11: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 1ApDFe-0007mS-2N; Fri, 06 Feb 2004 16: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 1ApDEh-0007as-T5 for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 16:10: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 QAA16860 for ; Fri, 6 Feb 2004 16:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDEg-000486-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 16:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDDz-00045A-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 16:09:19 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ApDD8-00041I-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 16:08:26 -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 F18751B3CCB; Fri, 6 Feb 2004 14:58:00 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> References: <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9C7A0F2C-58E8-11D8-A6E8-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Fri, 6 Feb 2004 15:08:28 -0600 To: John Schnizlein X-Mailer: Apple Mail (2.612) 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 On Feb 6, 2004, at 2:36 PM, John Schnizlein wrote: > Let us not forget that this stipulation of royalty-free is unusual. > Most IPR statements claim only the typical RAND statement. > What is the reason for suddenly requiring the unusual IPR statement in > DHC? Because the "RAND statement" is insufficient. If I am distributing open-source software, I can't afford to pay you a royalty on the offchance that someone might use your patented technique, even if the royalty is "reasonable" by some standard. I don't think it's even generally to your advantage to use the RAND terms, because it means that your devices can't be supported by open-source software. I suppose it might sell a few extra copies of Network Registrar. > Following the link Ralph posted, the Motorola-DHCP statement > includes the usual RAND: Yup. I have no idea to what this statement applies. I'm no happier about it than I am about Cisco's statement, but at this point it's a fait accompli, so there's no point in arguing about it. This IPR statement was also never announced to the WG. > Do you want to empower a company unrelated to the authors to block > progress on a specification simply by filing a subjunctive statement: > "that we may obtain intellectual property rights" No. Unfortunately, the present legal situation is that they can. If you don't like that, contact your congresscritter - don't complain to me. > Why is the IPR surprise and repair from PacketFront considered a reason > to demand a new, unusual standard of zero-royalty from Cisco? If you were to read the actual messages in the thread to which you were responding, you would already know the answer to this question. > Note that there was no surprise in that filing since the original draft > draft-droms-agentopt-8021x-00.txt in Nov 2001 included a RAND > statement with a not-subjunctive patent declaration. Putting an IPR statement at the bottom of an obscure draft that defines something very simple and obvious, that nobody would ever expect anybody to patent, isn't sufficient. If you are claiming a patent on something, you should say so explicitly when you announce the draft, or when, subsequent to announcing the draft, you decide to add the IPR statement. It has apparently become our collective job to read the IPR statement at the bottom of every copy of every draft that goes by to make sure there's no stealth patent claim, but tragically I wasn't aware of this until today. Normally, I read drafts for technical issues, not for legal issues. :'( _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 16:59:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24459; Fri, 6 Feb 2004 16:59:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApE07-000338-EL; Fri, 06 Feb 2004 16:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDzp-000304-JL for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 16:58:45 -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 QAA24311 for ; Fri, 6 Feb 2004 16:58:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDzn-0005Px-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 16:58:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDyf-0005AY-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 16:57:35 -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 1ApDwW-0004aT-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 16:55:20 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2004 14:01:28 +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 i16Lsl9T026683; Fri, 6 Feb 2004 13:54:47 -0800 (PST) Received: from kkinnear-w2k03.cisco.com ([161.44.65.247]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFW71882; Fri, 6 Feb 2004 16:54:46 -0500 (EST) Message-Id: <4.3.2.7.2.20040206163656.026cd7d0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 16:54:45 -0500 To: Ted Lemon , John Schnizlein From: Kim Kinnear Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Cc: dhcwg@ietf.org, kkinnear@cisco.com In-Reply-To: <9C7A0F2C-58E8-11D8-A6E8-000A95D9C74C@fugue.com> References: <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> 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=CASHCASHCASH 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: , Ted, You said: >Putting an IPR statement at the bottom of an obscure draft that defines something very simple and obvious, that nobody would ever expect anybody to patent, isn't sufficient. If you are claiming a patent on something, you should say so explicitly when you announce the draft, or when, subsequent to announcing the draft, you decide to add the IPR statement. It has apparently become our collective job to read the IPR statement at the bottom of every copy of every draft that goes by to make sure there's no stealth patent claim, but tragically I wasn't aware of this until today. Normally, I read drafts for technical issues, not for legal issues. :'( Stealth patent claim? Its in the draft precisely so it isn't stealth, for goodness sake! And, frankly, folks, it is not a big deal. Nobody is dumb enough to charge royalties. Don't be naive. If any company *made* it a big deal by charging $$, all of the goodwill they get from their customers for working with the IETF would be out the window. It would be a major black eye from a marketing standpoint. Why would anyone work with the IETF at all? For the good of mankind? Well, sure, that's why we do it -- but why does my boss let me? Because it *is* good for the industry and because our customers know it and our customers appreciate standards based solutions. Anyone who would invest time with the IETF and then blow it all away by charging royalty $$ would deserve the black eye they'd get from it. This isn't a big deal, and I don't know why people are trying to make it so. Talk to a marketing person about it, why don't you. I'm not saying that someone won't file a patent and hold us all up about it for big $$$ -- I'm saying that they won't work with the IETF to any great degree and then do that. -------- A slightly different issue ---------------------- Anyway, Ted, your personal issues on royalty-free as opposed to the more normal wording is, in practice, going to create more problems than it solves in the DHC WG. You should take this up with the overall IETF, and get the policy changed, if you want to (though I believe it isn't necessary) But if you filibuster every non-zero royalty IPR, then here is what can happen... I have submitted a patent for some technology (the server-id-override stuff) that I thought was pretty unique, for two reasons: 1. So that someone else doesn't patent it and force me to not use it (since I can't assume they will do the "reasonable and not ..." approach). 2. I get something slightly more than token $$ from my company. If you think I need the $$ enough for #2 to the sole reason, you've never worked with a patent lawyer, believe you me! Well, I also get a plaque someday. Wow! But, while my company has never, to my knowledge, asked for any $ for any of the IETF patents/IPR's we've got, I can't personally force them to make a patent that I seek be a guaranteed zero $ patent. So, when I write a draft about new technology, I have two choices. I can file the patent first, so that we can all use it (since I actually trust my company to continue to do what they've always done in this regard, for the reasons I expressed above), or I can skip it and just submit the draft. Of course, the next fellow who may write that patent may well not have the same interests that we do in this, and then *none* of us get to use it. If I think you will prevent the draft from moving forward, then I may skip the patent. And the other guy may not even tell us about their patent(s) until after we've all started using the technology and become dependent on it. Is this the choice you want me to make? Seriously? Thanks for listening -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 17:06:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25016; Fri, 6 Feb 2004 17:06: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 1ApE6r-0003X0-LY; Fri, 06 Feb 2004 17: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 1ApE6p-0003Wn-Mw for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 17:05: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 RAA25010 for ; Fri, 6 Feb 2004 17:05:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApE6n-00069g-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 17:05:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApE5r-00067T-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 17:05:00 -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 1ApE5f-00065C-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 17:04:48 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Feb 2004 14:11:36 +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 i16M4FT5012781; Fri, 6 Feb 2004 14:04:15 -0800 (PST) Received: from mjs-xp.cisco.com ([161.44.65.244]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFW72658; Fri, 6 Feb 2004 17:04:14 -0500 (EST) Message-Id: <4.3.2.7.2.20040206162911.01d58ab0@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 17:02:04 -0500 To: Ted Lemon From: Mark Stapp Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Cc: John Schnizlein , dhcwg@ietf.org In-Reply-To: <9C7A0F2C-58E8-11D8-A6E8-000A95D9C74C@fugue.com> References: <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> 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.0 required=5.0 tests=none 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 an ietf-wide issue, and this is the wrong forum for it. the ietf has had a consistent expectation, and that's what companies have met. it doesn't make sense to me to try to establish a different expectation in this one working group. if you want to change the way that the ietf handles IP (Intellectual Property, I mean, not the other thing) and IP licensing, more power to you and godspeed. take your issue to the proper forum - take it to the IPR WG, for example, or to the IAB. it doesn't make sense to me to complain that the ietf expectation is wrong, and that the ietf wg that's working on the issue is also wrong, and so the only way to get the policy to be what you want is to make some other wg do something different from the ietf as a whole. the tone of this thread has gotten a little hysterical, it seems to me. it's not really the thing to suggest that cisco people are trying to compete with you unfairly because they have a bigger legal department than nominum does. the cisco people who contribute to this wg are, as you know well, committed to doing the right thing. Let's take the thread back to the specific issue: I objected to the initial, vague packetfront IPR statement because I didn't like the implication that someone could stop progress in the standards body without substantial claims. the vague statement has been amended and brought in line with ietf expectations. I'm not aware of any DHC work that has related IPR statements that don't meet the ietf's expectations. it may even have been a good thing that we've had this blow-up, because it will certainly make us more aware of the issues going forward. now that the issue has been resolved, I'd like to continue the progress of this draft. -- Mark At 03:08 PM 2/6/2004 -0600, Ted Lemon wrote: >On Feb 6, 2004, at 2:36 PM, John Schnizlein wrote: >>Let us not forget that this stipulation of royalty-free is unusual. >>Most IPR statements claim only the typical RAND statement. >>What is the reason for suddenly requiring the unusual IPR statement in DHC? > >Because the "RAND statement" is insufficient. If I am distributing >open-source software, I can't afford to pay you a royalty on the offchance >that someone might use your patented technique, even if the royalty is >"reasonable" by some standard. I don't think it's even generally to your >advantage to use the RAND terms, because it means that your devices can't >be supported by open-source software. I suppose it might sell a few >extra copies of Network Registrar. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 17:47:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26905; Fri, 6 Feb 2004 17:47: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 1ApEkX-0006r1-A5; Fri, 06 Feb 2004 17: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 1ApEje-0006kC-7m for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 17:46:06 -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 RAA26815 for ; Fri, 6 Feb 2004 17:46:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEjb-0001Hv-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 17:46:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEif-0001EU-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 17:45:06 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ApEi2-0001BH-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 17:44:26 -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 57AF11B3DF1; Fri, 6 Feb 2004 16:34:00 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040206163656.026cd7d0@goblet.cisco.com> References: <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <200402061329.i16DT0r11498@cichlid.raleigh.ibm.com> <4.3.2.7.2.20040206144519.02205e38@wells.cisco.com> <4.3.2.7.2.20040206163656.026cd7d0@goblet.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <06362392-58F6-11D8-A6E8-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Fri, 6 Feb 2004 16:44:29 -0600 To: Kim Kinnear X-Mailer: Apple Mail (2.612) 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 On Feb 6, 2004, at 3:54 PM, Kim Kinnear wrote: > If I think you will prevent the draft from moving forward, then I > may skip the patent. And the other guy may not even tell us > about their patent(s) until after we've all started using the > technology and become dependent on it. > > Is this the choice you want me to make? Seriously? I am pretty sure that it doesn't matter which of these two avenues you pursue, as long as you publish the draft before the stealth patent is filed. I am not arguing that people shouldn't do defensive patents. I am arguing that this wg should not advance drafts that have patent terms that could be used to prevent the distribution of open source software or that could be damaging to companies that have no patent portfolio for cross-licensing. I am trying to be consistent with regard to various drafts that are under consideration by the wg - it is not at all my intention to say that any of the companies who have IP interests in these drafts actually have any bad intentions, and indeed we have a long history that suggest otherwise, at least in the case of Cisco (maybe in the case of PacketFront as well, but I'd never heard of them until this came up). It is not even my motivation to defend Nominum from some imagined future problem like this - Nominum is a commercial entity, not an individual open source developer. So I'm speaking with my Ted hat on, not my Nominum hat (indeed, I think the folks at Nominum would be quite dismayed if I claimed to represent Nominum's opinions here!). It is my right as a member of the WG to make this argument against a draft. It is the right of other members of the WG to agree with me, or to disagree with me. It is Ralph's job to decide whether or not there's consensus to advance the draft. We are all doing our jobs here; there's no need to get emotional about this. Having said that, I must apologize for overstepping the bounds of my job as a WG participant. It was pointed out to me that my position toward PacketFront was inconsistent with my position toward Cisco. In the process of trying to establish some consistency, I responded in a very defensive way to John, and said some things about the circumstances of the release of the Cisco 802.1x suboption draft which I do not know to be true, based solely on my admittedly poor memory. I also said something that for some readers seemed to imply that I thought Cisco was planning something nefarious. This is not what I meant - I was just explaining the logical reasoning behind preferring "zero royalty" to "reasonable" in an IPR statement. I am sorry for having gone overboard in my response to John, and I'm particularly sorry for any offense I may have caused to the folks at Cisco, many of whom I have worked with for over a decade in various corporate incarnations, and all of whom, including John, I hold in very high esteem. It's been a privilege working with all of you lo these many years, and I absolutely hate feeling like I'm at odds with you. I am not going to withdraw my argument for not advancing the subscriber-id draft, because I believe it is correct, and within the purview of this wg. If Ralph determines that I'm the lone wolf here, I will respect the wg's decision. I encourage other members of the WG to make their wishes known, whether they agree with me or disagree with me, but I hope that despite my own example we will not get into a long flamewar on the pros and cons of software patents. We are all reasonable people here, and have been at IETF long enough to know that we are not going to convert each other. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 18:18:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29192; Fri, 6 Feb 2004 18:18: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 1ApFEX-0005zI-0I; Fri, 06 Feb 2004 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 1ApFDb-0005kF-P1 for dhcwg@optimus.ietf.org; Fri, 06 Feb 2004 18:17: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 SAA29026 for ; Fri, 6 Feb 2004 18:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApFDY-0003NN-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 18:17:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApFCc-0003JU-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 18:16:02 -0500 Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx with esmtp (Exim 4.12) id 1ApFBm-0003Fn-00 for dhcwg@ietf.org; Fri, 06 Feb 2004 18:15:10 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.11/8.12.11) id i16NF4kl088593 for dhcwg@ietf.org env-from ; Fri, 6 Feb 2004 16:15:04 -0700 (MST) Date: Fri, 6 Feb 2004 16:15:04 -0700 (MST) From: Vernon Schryver Message-Id: <200402062315.i16NF4kl088593@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt References: <4.3.2.7.2.20040206163656.026cd7d0@goblet.cisco.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=CASHCASHCASH 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: , > From: Kim Kinnear > ... > And, frankly, folks, it is not a big deal. Nobody is dumb enough > to charge royalties. Don't be naive. If any company *made* it a > big deal by charging $$, all of the goodwill they get from their > customers for working with the IETF would be out the window. It > would be a major black eye from a marketing standpoint. Why > would anyone work with the IETF at all? For the good of mankind? > Well, sure, that's why we do it -- but why does my boss let me? > Because it *is* good for the industry and because our customers > know it and our customers appreciate standards based solutions. - "Reasonable" terms are in the eye of the beholder. - making money from license fees is not the only reason to get a patent. Preventing other implementations is at least as common a reason for filing as fees. The IP vultures that pick over the bones of dead companies are most likely to try to make money from fees. - goodwill from customers through working with the IETF doesn't increase the price of the stock or ship product. - organizations have varying motives for paying their employees to participate in the IETF. Getting IETF gold stars is rarely a major concern. > Anyone who would invest time with the IETF and then blow it all > away by charging royalty $$ would deserve the black eye they'd > get from it. This isn't a big deal, and I don't know why people > are trying to make it so. Talk to a marketing person about it, > why don't you. I have no idea whether the technical issue in this case is a big deal. It does seem to me that the precedent proposed of demanding free except for defensive licenses differs from the official IETF stance after the earliest IEST/IETF errors, but it is attractive. "Reasonable and non-discriminatory" has means one thing to an outfit trying some embracing and extending but something else to commercial competitors as well as people writing open source. > I'm not saying that someone won't file a patent and hold us all > up about it for big $$$ -- I'm saying that they won't work with > the IETF to any great degree and then do that. To avoid opening old, painful, lifethreatening (to the IETF), and poorly healed wounds, let's not talk in public about the IETF's and IESG's past "IP" mistakes and the organizations that did just what you say none would do. If you can't name any of the cases I'm thinking about, please ask around in private--but not me. Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 6 18:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29657; Fri, 6 Feb 2004 18:34: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 1ApFU1-0007MA-As; Fri, 06 Feb 2004 18: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 1AoSwq-00078E-9F for dhcwg@optimus.ietf.org; Wed, 04 Feb 2004 14:44: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 OAA22107 for ; Wed, 4 Feb 2004 14:44:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoSwn-00049E-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 14:44:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoSvu-00043I-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 14:43:35 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AoSv5-0003ws-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 14:42:43 -0500 Received: from thecount.psp.pas.earthlink.net ([207.217.78.22]) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AoSv1-0007aH-00 for dhcwg@ietf.org; Wed, 04 Feb 2004 11:42:39 -0800 Message-ID: <15627490.1075923759131.JavaMail.root@thecount.psp.pas.earthlink.net> Date: Wed, 4 Feb 2004 11:42:37 -0800 (GMT-08:00) From: Onik Nazarian Reply-To: Onik Nazarian To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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] DHCP Server 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, After installing DHCP server on Windows 2000 some workstion pick up IP address from excluded IP range. Please let me to know what I am doing wrong. I appreciate your help, Onik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 7 18:14:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17568; Sat, 7 Feb 2004 18:14: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 1ApbeE-0007qX-FT; Sat, 07 Feb 2004 18:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apbe7-0007np-Bo for dhcwg@optimus.ietf.org; Sat, 07 Feb 2004 18:13: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 SAA17491 for ; Sat, 7 Feb 2004 18:13:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apbe4-0006tc-00 for dhcwg@ietf.org; Sat, 07 Feb 2004 18:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApbdA-0006nz-00 for dhcwg@ietf.org; Sat, 07 Feb 2004 18:12:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApbcH-0006ir-00 for dhcwg@ietf.org; Sat, 07 Feb 2004 18:12:01 -0500 Received: from tortoise.webcentre.net ([62.189.30.6]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApbT9-0000tZ-7v for dhcwg@ietf.org; Sat, 07 Feb 2004 18:02:35 -0500 Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by tortoise.webcentre.net (8.9.3/8.9.3) with ESMTP id WAA07662 for ; Sat, 7 Feb 2004 22:58:37 GMT Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i17Mr4Or028452 for ; Sat, 7 Feb 2004 22:53:04 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA09783 for ; Sat, 7 Feb 2004 22:53:01 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i17Mr1m30832 for dhcwg@ietf.org; Sat, 7 Feb 2004 22:53:01 GMT Date: Sat, 7 Feb 2004 22:53:01 +0000 From: Tim Chown To: DHCPWG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <20040207225301.GB30700@login.ecs.soton.ac.uk> Mail-Followup-To: DHCPWG References: <4.3.2.7.2.20040204170501.04687cb0@flask.cisco.com> <4023D31C.5060206@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4023D31C.5060206@india.hp.com> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information 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 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 issues draft will be submitted for Monday's deadline so will be on the table in Seoul (Stig is presenting...) So #2 might well lead to #1 soon... Tim On Fri, Feb 06, 2004 at 11:17:08PM +0530, Vijayabhaskar A K wrote: > Solution 1 seems more logical to me.. I support solution 1 > > Vijay > > Ralph Droms wrote: > > >The IESG has one remaining comment on this draft (see > >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=896&filename=draft-ietf-dhc-dhcpv6-opt-nisconfig): > > > > > > what does a DHCPv6 server do when it wants to indicate that there's > >a NIS > > server available with an IPv4 address and another NIS server > >available with > > an IPv6 address? > > > > The two reasons why this can be a silly question: > > > > - NIS wouldn't work with such a config, so all the servers' addresses > > obviously have to be one address type > > - You can always encode a v4 address as a v6 address using the > >96-zeroes > > convention (or something else), so it's obvious how to do it > > > > But I think the document should address the issue. > > > >We have a couple of alternatives to addressing the issue: > > > >1. Reserve DHCPv6 for IPv6 NIS servers and DHCPv4 for IPv4 NIS servers > >2. Wait until the WG completes its work on DHCPv4/DHCPv6 issues > >3. Use an encoding to carry IPv4 addresses in the DHCPv6 option; for > > example, Vijay suggests: > > > > 3. Network Information Service (NIS) Servers Option > > > > The Network Information Service (NIS) Servers option provides a > > list of one or more IPv6 addresses of NIS servers available to the > > client. If any of the NIS servers is available with an IPv4 > >address, > > then its address will be represented in "IPv4-mapped IPv6 > >address" [RFC3513] > > format. Clients MUST treat the list of NIS servers as an ordered > > list. The server MAY list the NIS servers in the order of > > preference. > > > >For the DHCPv6 DNS servers option, the WG opted for alternative 1, which > >seems to me to be the right thing to do for the NIS servers option, as > >well. > > > >- Ralph > > > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > -- > __________________________________________________________ > Vijayabhaskar A K Phone : +91-80-22053085 > Hewlett Packard Mobile: +91-9845241382 > Bangalore, India Email : vijayak@india.hp.com > > Intellectuals solve problems: geniuses prevent them. > -Albert Einstein, physicist, Nobel laureate (1879-1955) > __________________________________________________________ > > > > _______________________________________________ > 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 Feb 7 21:33:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21589; Sat, 7 Feb 2004 21:33: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 1Apekn-0005q7-2z; Sat, 07 Feb 2004 21: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 1Apekg-0005p3-HL for dhcwg@optimus.ietf.org; Sat, 07 Feb 2004 21:32: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 VAA21578 for ; Sat, 7 Feb 2004 21:32:51 -0500 (EST) From: Shawbl19@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apekd-0006aH-00 for dhcwg@ietf.org; Sat, 07 Feb 2004 21:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apejj-0006Wk-00 for dhcwg@ietf.org; Sat, 07 Feb 2004 21:31:56 -0500 Received: from imo-m06.mx.aol.com ([64.12.136.161]) by ietf-mx with esmtp (Exim 4.12) id 1Apej7-0006Og-00 for dhcwg@ietf.org; Sat, 07 Feb 2004 21:31:17 -0500 Received: from Shawbl19@aol.com by imo-m06.mx.aol.com (mail_out_v36_r4.12.) id l.15d.2d3c0abe (3940) for ; Sat, 7 Feb 2004 21:30:39 -0500 (EST) Message-ID: <15d.2d3c0abe.2d56f94f@aol.com> Date: Sat, 7 Feb 2004 21:30:39 EST To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1076207439" X-Mailer: 9.0 for Windows sub 5003 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_30_40, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Subject: [dhcwg] 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: , -------------------------------1076207439 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I have a paper due on dhcp. I was wondering if you could send me any information on dhcp. I am taking a course for my MCSE and we have a papers due every month and this month mine is on dhcp. Any information will be greatly appreciated. Brian -------------------------------1076207439 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I have a paper due on dhcp. I was wondering if you could send me any in= formation on dhcp. I am taking a course for my MCSE and we have a papers due= every month and this month mine is on dhcp. Any information will be greatly= appreciated.
 
Brian
-------------------------------1076207439-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 11:07:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25187; Mon, 9 Feb 2004 11:07: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 1AqDw6-0000YD-R1; Mon, 09 Feb 2004 11:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDqQ-0000Io-Kc for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 11:01: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 LAA25012 for ; Mon, 9 Feb 2004 11:01:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDqO-0002tx-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 11:01:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDpT-0002p4-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 11:00:11 -0500 Received: from ns.cnri.reston.va.us ([132.151.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDon-0002kd-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 10:59:29 -0500 Received: from cnri-7-43.cnri.reston.va.us ([132.151.7.43] helo=marcia.cnri.reston.va.us) by ns.cnri.reston.va.us with esmtp (Exim 4.20) id 1AqDoi-00048w-OR; Mon, 09 Feb 2004 10:59:25 -0500 Message-Id: <5.1.0.14.2.20040209105412.01feadd0@odin> X-Sender: mbeaulie@odin X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Feb 2004 10:59:20 -0500 To: Ralph Droms From: Marcia Beaulieu Cc: Margaret.Wasserman@nokia.com, narten@us.ibm.com, dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20031224071615.029d6c78@flask.cisco.com> References: <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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] 59th IETF - DHC 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 to confirm that DHC is currently scheduled on Tuesday, March 2 at 0900-1130 Other groups scheduled at that time are: crisp, psamp, forces, avt =================================================================== If you have not already done so, please submit the agenda for your working group meeting by Tuesday, February 24 at 12:00noon ET to agenda@ietf.org. You will find the blue sheet (roster) and white sheet (Proceedings Submission Form) in a file folder on the head table in the room your working group will meet. Please pass the blue sheet around the room at the beginning of the session (a clipboard and pen will be provided for your convenience) to record attendance. Please turn the blue sheet and completed white sheet in at the IETF Registration desk following the conclusion of your working group session. The deadline for submission of minutes and presentation slides for inclusion in the proceedings of the 59th IETF Meeting is Friday, April 2, 2004 at 17:00 ET. Please send all materials to proceedings@ietf.org by that time. Any materials received after that time will not be included. Please note that submission of minutes is mandatory, while submission of presentation slides is optional. Minutes may be submitted in plain text (Unix/Mac/Dos) or in simple HTML with no style sheets. Minutes submitted in plain text will be reformatted by the Secretariat. Therefore, if you are concerned about preserving the formatting of your minutes, then please submit them in HTML. Presentation slides may be submitted in any of the following formats: .TXT Plain text (Unix/Mac/Dos) .DOC MS Word Document (v95 - 2000) .PDF Adobe Portable Document Format (Acrobat 3, 4, 5, 6) .PPT MS PowerPoint (v95 - 2000) When submitting slides for multiple presentations, please indicate the order that the presentations should appear in the proceedings. Input to the proceedings, which has been processed to conform with established proceedings standards (as described above), will be posted within 48 hours after receipt at: www.ietf.org/proceedings/04mar/index.html . Please review your materials on line and send any corrections to: proceedings@ietf.org . The deadline for submitting corrections is Friday, April 16, 2004 at 17:00 ET. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 11:48:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27949; Mon, 9 Feb 2004 11:48: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 1AqEZk-00050u-7C; Mon, 09 Feb 2004 11:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEYx-0004zh-7U for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 11:47:11 -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 LAA27850 for ; Mon, 9 Feb 2004 11:47:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEYw-0000UK-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 11:47:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEY4-0000OY-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 11:46:17 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AqEXE-0000DG-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 11:45:24 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4996D61B91; Mon, 9 Feb 2004 17:44:52 +0100 (CET) Date: Mon, 09 Feb 2004 08:40:18 -0800 From: Harald Tveit Alvestrand To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <2427813621.1076316018@localhost> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========D26A0850799FF06B2EEC==========" 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 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: , --==========D26A0850799FF06B2EEC========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ted, thinking about this some more.... I know that you have worked on this far=20 longer than I have, and that the role I'm playing here of saying "the=20 current solution is not reasonable" is not a very pleasant one..... I think you have to do some basic decision-making first - first off, is=20 this the Dynamic HOST Configuration Protocol or the Dynamic INTERFACE=20 Configuration Protocol? For a lot of parameters (such as address and netmask), it seems to be=20 interface (or stack). But for many (such as NIS server and SNTP server), it = is definitely host. And those are the ones for which we have the problem. If I think of the problem of host configuration from the viewpoint of a=20 network admin, what I want is to get a set of parameters from my=20 configuration files into the running config of a host, without having to=20 ask the user to do anything but connect. Having the possibility multiple=20 overlapping and interacting configurations doesn't help my job, it=20 complicates it. So - viewing this as a HOST configuration problem, I think the problem=20 reduces to getting multiple sets of configurations, via multiple=20 interfaces/protocols, deciding on one and only one set to use for HOST=20 configuration, and ignoring the rest. This means that ONE set has to be able to contain ALL the parameters a=20 sysadmin wants to set that has HOST scope. Back to the v4/v6 case: DHCPv4 is useful for IPv4-only hosts, of which we will still have a lot for = a few (?) years. For dual-stack hosts, of which we will hopefully have many soon, a single=20 configuration mechanism that is able to set HOST parameters for both IPv4=20 and IPv6-related data is required. For IPv6-only hosts, of which we will hopefully have more than a few in the = future, it should be easy to use the same mechanism by not setting the=20 IPv4-related values. So - what I'd think was a sensible thing to do: - Mark each and every DHCPv6 configuration parameter with "Interface=20 specific" or "Host specific". - For "Host specific", make it easy for a host to figure out which set of=20 parameters it uses, and let it stick to that set only. No mixing! - Make sure that all "Host specific" parameters are able to specify values=20 that make sense for both IPv4 and IPv6 - In all the instances I've seen so far, declare that if you need an IPv4=20 address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) - no=20 other changes needed. and most difficult: - declare WG consensus for all this while KRE still disagrees :-) (I recognize that KRE has a logically coherent argument. I just happen to=20 think that he's wrong. That's life!) I may now have repeated a proposal that was suggested and rejected 3.5=20 years ago - that's life too. But you asked...... Harald --On 5. februar 2004 18:22 -0600 Ted Lemon wrote: > You are totally right. This sucks. The problem is that the > alternative is even worse. This isn't even strictly an IPv4/IPv6 issue > - consider what happens when you have two network interfaces that are > configured by two different servers in two different administrative > domains! > > Unfortunately, we haven't been able to think of a way to specify how DHCP > devices should deal with this problem. It's easy to specify a scenario, > and then say what should be done in that scenario, but it's hard to > specify a set of rules that will work in all scenarios. > > Anyway, you have to support both protocols, because you might be on an > IPv4-only or IPv6-only network, so even if we specified a way to > configure your IPv4 stack with DHCPv6, you'd still have to implement a > DHCPv4 client. :'( > > It's possible that when we have some real-world experience with this, we > might have enough information to make a stab at specifying a general > solution to this problem, but I don't think we do right now, and if we > tried, we'd wind up in ten-years-later land. > > If you have an idea for a general solution, we'd all like to hear it, by > the way. But please remember that we're not complete dummies, and try > to think about six chess moves ahead rather than just stating an obvious, > but wrong, idea, because we've probably already considered and discarded > that idea. > --==========D26A0850799FF06B2EEC========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFAJ7f3OMj+2+WY0F4RArzXAJ9KFzK1gp/ph1nN4LyCJc05Oc4MQgCg8vjR Npg0k6wC254WAEUQwIRv0is= =4Vl8 -----END PGP SIGNATURE----- --==========D26A0850799FF06B2EEC==========-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 12:21:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28954; Mon, 9 Feb 2004 12:21: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 1AqF5h-0007hi-NF; Mon, 09 Feb 2004 12:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF4y-0007fP-7V for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 12:20: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 MAA28899 for ; Mon, 9 Feb 2004 12:20:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF4w-0003PS-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:20:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF41-0003Kc-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:19:17 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AqF3D-00039u-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:18:27 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2004 09:17:56 -0800 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 i19HHrxH013050; Mon, 9 Feb 2004 12:17:54 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFX66819; Mon, 9 Feb 2004 12:17:52 -0500 (EST) Message-Id: <4.3.2.7.2.20040209121430.01fd9990@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Feb 2004 12:17:50 -0500 To: Harald Tveit Alvestrand From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Cc: Ted Lemon , dhcwg@ietf.org In-Reply-To: <2427813621.1076316018@localhost> 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.0 required=5.0 tests=AWL 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: , Looks like we will have two drafts on this issue to read and discuss in a day or two: "DHCPv6 IPv4 Information Options" draft-cadar-dhc-dhcpv6-v4options-00 "IPv4 and IPv6 Dual-Stack Issues for DHCPv6" draft-chown-dhc-dual-stack-00 - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 12:22:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29014; Mon, 9 Feb 2004 12:22: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 1AqF6e-0007q3-Ch; Mon, 09 Feb 2004 12:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF5s-0007is-O0 for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 12:21: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 MAA28947 for ; Mon, 9 Feb 2004 12:21:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF5r-0003UP-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:21:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF52-0003QM-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:20:21 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AqF4L-0003Lb-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:19:37 -0500 Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 0DABE1B2E29; Mon, 9 Feb 2004 11:08:38 -0600 (CST) In-Reply-To: <2427813621.1076316018@localhost> References: <2427813621.1076316018@localhost> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1F64DC40-5B24-11D8-93AF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Date: Mon, 9 Feb 2004 11:19:31 -0600 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.612) 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 > - Mark each and every DHCPv6 configuration parameter with "Interface > specific" or "Host specific". All of your proposals have been discussed before, and in fact at least some have been implemented, although I just reread parts of RFC3315 and was unable to find a place where you would have been able to easily find out about this. In particular, DHCPv6 uses option encapsulation pretty heavily to form a hierarchy of applicability. A DHCP packet contains options. Some of these options are identity associations. Identity associations generally correspond to interfaces, although some hosts may have more than one identity per interface. Within each identity association there may be one or more IP address options, each of which can itself contain options. Options that are contained within IP address options are specific to that IP address. Options contained in identity association options are specific to that identity association (e.g., interface). Options at the top level are general - they apply regardless of the identity association. So you'd put the IP address of your name server there, most likely. In reviewing RFC3315 with what you've said in mind, I realize that it doesn't ever explicitly say this, or at least I can't find where it says it. It's all there in a way in the definitions of the various options, but you'd have to read the draft pretty carefully and creatively to realize that what I've said is what's being implied. > - For "Host specific", make it easy for a host to figure out which set > of parameters it uses, and let it stick to that set only. No mixing! Okay, but how do we specify this? I guess saying "no mixing" is pretty easy, but I don't see how we can go beyond that, and I'm not sure that just specifying that is going to result in reliable behavior - it's easy to imagine a dumb DHCP client stubbornly making the wrong choice every single time. > - Make sure that all "Host specific" parameters are able to specify > values that make sense for both IPv4 and IPv6 I'm not sure we've been doing this, but I agree that it's a reasonable thing to do. > - In all the instances I've seen so far, declare that if you need an > IPv4 address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) > - no other changes needed. So are you saying that a DHCPv6 client should be able to acquire IPv4 addresses, or just that when it gives the addresses of the DNS server, it should be able to give the IPv4 addresses as well as the IPv6 addresses? I can see a lot of problems with the former; in the case of the latter, it makes sense, although I would argue that the server administrator should be able to enable or disable IPv4 to IPv6 address mapping, because I can imagine cases where you'd want it and cases where you wouldn't. > I may now have repeated a proposal that was suggested and rejected 3.5 > years ago - that's life too. But you asked...... It's good that you're asking these questions. I'm sorry for dumping a pile more on you, but I am definitely interested in your answers. We needed to kick 3315 out the door, for obvious reasons, but that doesn't mean that it requires no further tweaking. Fortunately, I don't think what we're talking about here requires any incompatible changes. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 12:55:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00875; Mon, 9 Feb 2004 12:55: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 1AqFcc-0002JY-55; Mon, 09 Feb 2004 12:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFbx-0002Iv-4s for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 12:54: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 MAA00841 for ; Mon, 9 Feb 2004 12:54:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFbv-0006lE-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:54:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFay-0006gG-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:53:21 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AqFaK-0006bB-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:52:40 -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 i19HqSGn018379; Mon, 9 Feb 2004 12:52:37 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" , "'Harald Tveit Alvestrand'" Cc: Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Date: Mon, 9 Feb 2004 12:52:35 -0500 Message-ID: <000801c3ef35$831e44d0$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 In-Reply-To: <1F64DC40-5B24-11D8-93AF-000A95D9C74C@fugue.com> Importance: 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=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 Hi: I do think it best we wait until some of the dual-stack issues are at = least partially discussed, so I'm looking forward to the two drafts Ralph mentioned. Regarding the issue of option scope, we did build this in to DHCPv6 but = I think we decided to avoid mentioning this explicitly since it would unnecessarily complicate things and we really weren't ready to go there = yet. Yes, with the scoping (encapsulation), it is possible for DHCPv6, for example, to assign a different domain name to each address (rather than = to all addresses on an interface or to a client). And, DHCP is really the Dynamic Interface Configuration Protocol. Why? Because everything we do is INTERFACE specific. Perhaps, even more correctly, would be to say it is the Dynamic Interface and Transport Configuration Protocol (because we're also IPv4 or IPv6 specific). When there was just DHCPv4, this typically wasn't a big deal UNLESS a = host had multiple interfaces. And, then it got nasty quickly especially if = the two interfaces were in different administrative domains. Which does the = host use? Now, we've added another dimension, the transport (IPv4 vs IPv6). This, = in many ways, makes all DUAL STACK hosts have multiple interfaces. We never really solved the multiple interfaces issue well in DHCPv4. One side of me says this is not a problem worth solving as it is = extremely complex and, especially with regard to transports, hopefully will be = short lived. But, I doubt we will transition to IPv6 quickly, so IPv4 will be around a long time. Personally, I'd like to keep DHCPv6 from providing IPv4 related = information, since I think it just makes things worse and also means IPv6 only hosts = will have stuff they never have a means to use. I think the correct answer is for the client to resolve the conflicts, = since it may be the only entity that knows best what to do with the = information (for example, it should know whether it is likely in the SAME or = DIFFERENT administrative domain depending on the context of the "interface" - = i.e., a VPN interface is likely in a different administrative domain). So, my two cents at this moment would be to say that the DHCPv4 and = DHCPv6 client must adjust the HOST configuration parameters properly to either MERGE the information or to keep it "contained" (such as for a VPN). In = many cases, this isn't a big deal and is made significantly easier when we = keep DHCPv4 to providing IPv4 only information and DHCPv6 to providing IPv6 = only information. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted Lemon Sent: Monday, February 09, 2004 12:20 PM To: Harald Tveit Alvestrand Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt > - Mark each and every DHCPv6 configuration parameter with "Interface=20 > specific" or "Host specific". All of your proposals have been discussed before, and in fact at least=20 some have been implemented, although I just reread parts of RFC3315 and=20 was unable to find a place where you would have been able to easily=20 find out about this. In particular, DHCPv6 uses option encapsulation pretty heavily to form=20 a hierarchy of applicability. A DHCP packet contains options. Some=20 of these options are identity associations. Identity associations=20 generally correspond to interfaces, although some hosts may have more=20 than one identity per interface. Within each identity association=20 there may be one or more IP address options, each of which can itself=20 contain options. Options that are contained within IP address options are specific to=20 that IP address. Options contained in identity association options=20 are specific to that identity association (e.g., interface). Options=20 at the top level are general - they apply regardless of the identity=20 association. So you'd put the IP address of your name server there,=20 most likely. In reviewing RFC3315 with what you've said in mind, I realize that it=20 doesn't ever explicitly say this, or at least I can't find where it=20 says it. It's all there in a way in the definitions of the various=20 options, but you'd have to read the draft pretty carefully and=20 creatively to realize that what I've said is what's being implied. > - For "Host specific", make it easy for a host to figure out which set = > of parameters it uses, and let it stick to that set only. No mixing! Okay, but how do we specify this? I guess saying "no mixing" is=20 pretty easy, but I don't see how we can go beyond that, and I'm not=20 sure that just specifying that is going to result in reliable behavior=20 - it's easy to imagine a dumb DHCP client stubbornly making the wrong=20 choice every single time. > - Make sure that all "Host specific" parameters are able to specify=20 > values that make sense for both IPv4 and IPv6 I'm not sure we've been doing this, but I agree that it's a reasonable=20 thing to do. > - In all the instances I've seen so far, declare that if you need an=20 > IPv4 address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) = > - no other changes needed. So are you saying that a DHCPv6 client should be able to acquire IPv4=20 addresses, or just that when it gives the addresses of the DNS server,=20 it should be able to give the IPv4 addresses as well as the IPv6=20 addresses? I can see a lot of problems with the former; in the case=20 of the latter, it makes sense, although I would argue that the server=20 administrator should be able to enable or disable IPv4 to IPv6 address=20 mapping, because I can imagine cases where you'd want it and cases=20 where you wouldn't. > I may now have repeated a proposal that was suggested and rejected 3.5 = > years ago - that's life too. But you asked...... It's good that you're asking these questions. I'm sorry for dumping a=20 pile more on you, but I am definitely interested in your answers. We=20 needed to kick 3315 out the door, for obvious reasons, but that doesn't=20 mean that it requires no further tweaking. Fortunately, I don't think=20 what we're talking about here requires any incompatible changes. _______________________________________________ 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 Mon Feb 9 14:31:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05936; Mon, 9 Feb 2004 14:31: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 1AqH7W-0001nq-7B; Mon, 09 Feb 2004 14: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 1AqH6s-0001mr-9Y for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 14:30:22 -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 OAA05900 for ; Mon, 9 Feb 2004 14:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH6p-00015A-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:30:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH5p-000104-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:29:18 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AqH5C-0000qz-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:28:38 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B67761C2B; Mon, 9 Feb 2004 20:28:06 +0100 (CET) Date: Mon, 09 Feb 2004 10:48:31 -0800 From: Harald Tveit Alvestrand To: Bernie Volz , "'Ted Lemon'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <2435506122.1076323711@localhost> In-Reply-To: <000801c3ef35$831e44d0$6401a8c0@BVolz> References: <000801c3ef35$831e44d0$6401a8c0@BVolz> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2EF4D756CBD215BBD9E4==========" 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 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: , --==========2EF4D756CBD215BBD9E4========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 9. februar 2004 12:52 -0500 Bernie Volz wrote: > And, DHCP is really the Dynamic Interface Configuration Protocol. Why? > Because everything we do is INTERFACE specific. Perhaps, even more > correctly, would be to say it is the Dynamic Interface and Transport > Configuration Protocol (because we're also IPv4 or IPv6 specific). Then stop trying to configure SNTP and NIS. --==========2EF4D756CBD215BBD9E4========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFAJ9YCOMj+2+WY0F4RAs3YAJsFn6XETXErnhBsJpXDVaEclFDpcACfaqmj uOwRILc6VHWMKqZnluM9e74= =A/bu -----END PGP SIGNATURE----- --==========2EF4D756CBD215BBD9E4==========-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 14:34:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06155; Mon, 9 Feb 2004 14:34: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 1AqHAO-0002FQ-Oh; Mon, 09 Feb 2004 14:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH9j-0002Ch-Jb for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 14:33: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 OAA06097 for ; Mon, 9 Feb 2004 14:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH9h-0001M9-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:33:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH8o-0001Gp-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:32:23 -0500 Received: from mail.gmellc.net ([69.3.229.106] helo=mail.gmellc.com) by ietf-mx with esmtp (Exim 4.12) id 1AqH8F-0001AL-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:31:47 -0500 Received: from pauljebe (unknown [192.168.8.3]) by mail.gmellc.com (Postfix) with SMTP id C824F40C0D6 for ; Mon, 9 Feb 2004 14:31:16 -0500 (EST) From: "Gregory Malsack" To: Date: Mon, 9 Feb 2004 13:28:28 -0600 Message-ID: <000201c3ef42$e5d16050$0308a8c0@pauljebe> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C3EF10.9B7272B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: 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 Subject: [dhcwg] multiple server configuration problems 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_0003_01C3EF10.9B7272B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello All, I have a client that has 5 locations, Milwaukee, Madison, Fond Du Lac, Green Bay, and Sussex. I am using 5 linux based routers to do encrypted pptp, and dhcp for each location. So far each location has been using static addresses for each computer, and all is well. However we just put the Madison location the pptp network, and switched them over to dhcp. (All sites have been on a p-t-p network with the same subnet until now) Now the computers on Friday the computers in Madison got dhcp addresses for the madison network. However, today (Monday) they are getting addresses for the milwaukee network. I've tried setting up firewall rules to stop udp traffic on port 67 from traversing the vpn, but that's not working. Can anyone tell me what I'm doing wrong? I have included a pdf of the various config files. --------------------- Gregory Malsack President Gregory Malsack Enterprises, LLC 262-650-0059 ------=_NextPart_000_0003_01C3EF10.9B7272B0 Content-Type: application/pdf; name="Configs.pdf" Content-Disposition: attachment; filename="Configs.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0NvdW50IDIgDS9LaWRz IFsgNCAwIFIgOSAwIFIgXSANPj4gDWVuZG9iag0yIDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyAN L1BhZ2VzIDEgMCBSIA0vQWNyb0Zvcm0gMTkgMCBSIA0vTWV0YWRhdGEgODIgMCBSIA0+PiANZW5k b2JqDTMgMCBvYmoNPDwgDS9UaXRsZSAoTWljcm9zb2Z0IFdvcmQgLSBEb2N1bWVudDEpDS9DcmVh dG9yIChXaW4yUERGIGh0dHA6Ly93d3cuZGFuZXByYWlyaWUuY29tKQ0vQXV0aG9yIChzY290dCkN L0NyZWF0aW9uRGF0ZSAoRDoyMDA0MDIwOTEwMzAxMlopDS9Qcm9kdWNlciAoUERGbGliIDMuMDMg XChXaW4zMlwpKQ0vTW9kRGF0ZSAoRDoyMDA0MDIwOTEzMjc0My0wNicwMCcpDT4+IA1lbmRvYmoN NCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMSAwIFIgDS9SZXNvdXJjZXMgPDwgL0Nv bG9yU3BhY2UgPDwgL0NTMjYgMjMgMCBSIC9DUzI1IDIzIDAgUiAvQ1MyNCAyMyAwIFIgL0NTMjMg MjMgMCBSIC9DUzIyIDIzIDAgUiANL0NTMjEgMjMgMCBSIC9DUzIwIDIzIDAgUiAvQ1MxOSAyMyAw IFIgL0NTMTggMjMgMCBSIC9DUzE3IDIzIDAgUiANL0NTMTYgMjMgMCBSIC9DUzE1IDIzIDAgUiAv Q1MxNCAyMyAwIFIgL0NTMTMgMjMgMCBSIC9DUzEyIDIzIDAgUiANL0NTMTEgMjMgMCBSIC9DUzEw IDIzIDAgUiAvQ1M5IDIzIDAgUiAvQ1M4IDIzIDAgUiAvQ1M3IDIzIDAgUiAvQ1M2IDIzIDAgUiAN L0NTNSAyMyAwIFIgL0NTNCAyMyAwIFIgL0NTMyAyMyAwIFIgL0NTMiAyMyAwIFIgL0NTMSAyMyAw IFIgL0NTMCAyMyAwIFIgPj4gDS9Gb250IDw8IC9UMV8yNiA3IDAgUiA+PiAvRXh0R1N0YXRlIDw8 IC9HUzI2IDEzIDEgUiA+PiAvUHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiANL01lZGlhQm94IFsg MCAwIDYxMiA3OTIgXSANL0NvbnRlbnRzIDc2IDAgUiANPj4gDWVuZG9iag03IDAgb2JqDTw8IA0v VHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyAN L0Jhc2VGb250IC9UaW1lcy1Sb21hbiANPj4gDWVuZG9iag05IDAgb2JqDTw8IA0vVHlwZSAvUGFn ZSANL1BhcmVudCAxIDAgUiANL1Jlc291cmNlcyA8PCAvQ29sb3JTcGFjZSA8PCAvQ1MxIDIzIDAg UiAvQ1MwIDIzIDAgUiA+PiAvRm9udCA8PCAvVDFfMSA3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAv R1MxIDEzIDEgUiA+PiAvUHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiANL01lZGlhQm94IFsgMCAw IDYxMiA3OTIgXSANL0NvbnRlbnRzIDgwIDAgUiANPj4gDWVuZG9iag0xMyAxIG9iag08PCANL1R5 cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNlIA0vT1AgZmFsc2UgDS9vcCBmYWxzZSANL09QTSAwIA0v QkcyIC9EZWZhdWx0IA0vVUNSMiAvRGVmYXVsdCANL1RSMiAvRGVmYXVsdCANL0hUIC9EZWZhdWx0 IA0vQ0EgMSANL2NhIDEgDS9TTWFzayAvTm9uZSANL0FJUyBmYWxzZSANL0JNIC9Ob3JtYWwgDS9U SyB0cnVlIA0+PiANZW5kb2JqDTE5IDAgb2JqDTw8IA0vRmllbGRzIFsgXSANL0RSIDw8IC9Gb250 IDw8IC9aYURiIDIwIDAgUiAvSGVsdiAyMSAwIFIgPj4gL0VuY29kaW5nIDw8IC9QREZEb2NFbmNv ZGluZyAyMiAwIFIgPj4gPj4gDS9EQSAoL0hlbHYgMCBUZiAwIGcgKQ0+PiANZW5kb2JqDTIwIDAg b2JqDTw8IA0vVHlwZSAvRm9udCANL05hbWUgL1phRGIgDS9CYXNlRm9udCAvWmFwZkRpbmdiYXRz IA0vU3VidHlwZSAvVHlwZTEgDT4+IA1lbmRvYmoNMjEgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0v TmFtZSAvSGVsdiANL0Jhc2VGb250IC9IZWx2ZXRpY2EgDS9TdWJ0eXBlIC9UeXBlMSANL0VuY29k aW5nIDIyIDAgUiANPj4gDWVuZG9iag0yMiAwIG9iag08PCANL1R5cGUgL0VuY29kaW5nIA0vRGlm ZmVyZW5jZXMgWyAyNCAvYnJldmUgL2Nhcm9uIC9jaXJjdW1mbGV4IC9kb3RhY2NlbnQgL2h1bmdh cnVtbGF1dCAvb2dvbmVrIC9yaW5nIA0vdGlsZGUgMzkgL3F1b3Rlc2luZ2xlIDk2IC9ncmF2ZSAx MjggL2J1bGxldCAvZGFnZ2VyIC9kYWdnZXJkYmwgDS9lbGxpcHNpcyAvZW1kYXNoIC9lbmRhc2gg L2Zsb3JpbiAvZnJhY3Rpb24gL2d1aWxzaW5nbGxlZnQgL2d1aWxzaW5nbHJpZ2h0IA0vbWludXMg L3BlcnRob3VzYW5kIC9xdW90ZWRibGJhc2UgL3F1b3RlZGJsbGVmdCAvcXVvdGVkYmxyaWdodCAv cXVvdGVsZWZ0IA0vcXVvdGVyaWdodCAvcXVvdGVzaW5nbGJhc2UgL3RyYWRlbWFyayAvZmkgL2Zs IC9Mc2xhc2ggL09FIC9TY2Fyb24gDS9ZZGllcmVzaXMgL1pjYXJvbiAvZG90bGVzc2kgL2xzbGFz aCAvb2UgL3NjYXJvbiAvemNhcm9uIDE2MCAvRXVybyANMTY0IC9jdXJyZW5jeSAxNjYgL2Jyb2tl bmJhciAxNjggL2RpZXJlc2lzIC9jb3B5cmlnaHQgL29yZGZlbWluaW5lIA0xNzIgL2xvZ2ljYWxu b3QgLy5ub3RkZWYgL3JlZ2lzdGVyZWQgL21hY3JvbiAvZGVncmVlIC9wbHVzbWludXMgDS90d29z dXBlcmlvciAvdGhyZWVzdXBlcmlvciAvYWN1dGUgL211IDE4MyAvcGVyaW9kY2VudGVyZWQgL2Nl ZGlsbGEgDS9vbmVzdXBlcmlvciAvb3JkbWFzY3VsaW5lIDE4OCAvb25lcXVhcnRlciAvb25laGFs ZiAvdGhyZWVxdWFydGVycyANMTkyIC9BZ3JhdmUgL0FhY3V0ZSAvQWNpcmN1bWZsZXggL0F0aWxk ZSAvQWRpZXJlc2lzIC9BcmluZyAvQUUgL0NjZWRpbGxhIA0vRWdyYXZlIC9FYWN1dGUgL0VjaXJj dW1mbGV4IC9FZGllcmVzaXMgL0lncmF2ZSAvSWFjdXRlIC9JY2lyY3VtZmxleCANL0lkaWVyZXNp cyAvRXRoIC9OdGlsZGUgL09ncmF2ZSAvT2FjdXRlIC9PY2lyY3VtZmxleCAvT3RpbGRlIC9PZGll cmVzaXMgDS9tdWx0aXBseSAvT3NsYXNoIC9VZ3JhdmUgL1VhY3V0ZSAvVWNpcmN1bWZsZXggL1Vk aWVyZXNpcyAvWWFjdXRlIA0vVGhvcm4gL2dlcm1hbmRibHMgL2FncmF2ZSAvYWFjdXRlIC9hY2ly Y3VtZmxleCAvYXRpbGRlIC9hZGllcmVzaXMgDS9hcmluZyAvYWUgL2NjZWRpbGxhIC9lZ3JhdmUg L2VhY3V0ZSAvZWNpcmN1bWZsZXggL2VkaWVyZXNpcyAvaWdyYXZlIA0vaWFjdXRlIC9pY2lyY3Vt ZmxleCAvaWRpZXJlc2lzIC9ldGggL250aWxkZSAvb2dyYXZlIC9vYWN1dGUgL29jaXJjdW1mbGV4 IA0vb3RpbGRlIC9vZGllcmVzaXMgL2RpdmlkZSAvb3NsYXNoIC91Z3JhdmUgL3VhY3V0ZSAvdWNp cmN1bWZsZXggDS91ZGllcmVzaXMgL3lhY3V0ZSAvdGhvcm4gL3lkaWVyZXNpcyBdIA0+PiANZW5k b2JqDTIzIDAgb2JqDS9EZXZpY2VHcmF5IA1lbmRvYmoNNzYgMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCA3NyAwIFIgPj4gDXN0cmVhbQ0KSIm8V9tuGzkSfTfgf+BjshgzZPGu t6wnAWYNTwzDwbwIWChWb6yJYwlSe43M12+V1Go3KVGk7MwqQOA4qitPnTol2NcTyWbs5N11cz9p Z/9tzuf38+Xse9MuZ7dsOTv5583Juxv5b7AMhPbs5j8nUgguGbv5iwkuhApM0J/NjxI4uGCYc8CN EPj97ydvLifT2Wr+wD7Ols3T5P7+7c2f5GTt4g1j3T85lHwazYWXZu3z/G4ye2C//X71+YaN3yzm 97PbH+z9+fmHqxsG9pItJrffmnb1C9Pai0v25UfbrMZv48h9YFuKrDUPQoZ1ZLb41q42Dlk7WX5t WkafxXLesvmiZZgWfeaPm9+v5o/L24bFn2mzasenswfs+Pxhf1LSlZJShjsAtUkKP4ExCF5vu0Cf x+niub8661EA986E2OXZWd8fnzX0HKSxaS5Ne4cAYf/oqsVv0593YtiCPb+kbKeLdjWybmR9pi3F twLLtQfXt2UTQLDrD//6cJ60JQSudMZh0NwaC7HDQVOydoGHYNM8ul68riVsfLps/mxu22FvdjNQ wvBgXZJDn7kwWTvPrXVJD59m7R2b3X5fFIJqwT3s9GsbNNtmpRXX1srYbjFfloo0+HUwJhMPcmyi TODCGh3bPT4sm8nt3eTLfZPBXS7/HnfScSW6CZBCXbBghbvoprHYBu+5llbHbuiDfFnGqpQ43srE WQywmntxKXFunVFJ2ASsMgDOnV9jk+YvBmumX9mQ234h2CRgRZuQ4IGBcsYP6YtqXzs03Hpil6cu gqAfDzZEIGNL9BaF2XQEkxNADg5zP7ZUBuK2KNE++pu0SxvXO240WgeXuLl6/IILi72fTpfNarVL AOTrrPOwSXSdJWjlDTdKKQxwMx2mU8WNNnjuvdpsZS8E4s04qy6GPW9vF5ueOy6lcsf0HMNoZ5Iw x/XccXQAsYfje24Q1cYlbl7ecyfQHYT9PS+taesDd0LDoX1EPS/vI+yusip2WDHjAXvqkF+TRLad 7O1VthBJHLHj4Kg9RhXiHhtJh3FqdhgEy6X3SbXFZIFeHPse29WuMCW5wF2UCZpfYUohP9nkrStW mLbceBMy8Ux+ZQbcbyZpTnmFFenBY1DQG4FtIWiBkkDDxV6oHlaUW/KMXA7AmmcA4jejYsMXy6cO dqsRqBES0PhUV4FPAW5DsC5Jv4g+Baj9rE3KrkWfxS3r09L7oD53cimrEfJEmkO7CvQ5JAavs0Vm BRR+XYNOiiyjL88vHfqcxEtDd0cW07icQAWtI/T1yAt5lvSGWHLorYZeSTGghPKxZQ1kRSB+tGkB r4WsHIFky/FpleAP3Fink9zLgp96L1zSrWrBjw0Dm4l5QO870t8htqvR+zRbJldjHq44VlaYpMYy XEv61dK4kt/1azuHKopk/+XRd6aUkpu1bBp6rBLvFrFOlUWpvPrUlESVenxaSZWYhCaqjLKvokrt iSqHdtVUiZJEpJXXUaXSRJVDuzqqxE2YLTKLPYeY1Top8iD2ECkhl34PPQM8gHGRpOyTyQ4e/t9a UcXWrxCiQ0fHCNE4gdfx5AibTzgdnxYVpfdIdj7Nu0iSEBBRGs/TyK4WqaCQ7WzIBM2zJOAJI2zy WhVIVR7Zbudx+ng+y8pIjtomRWaRyorz3WNVaW7o0CR/53eT2QP7+On6j/fXv7Ix1oMX2Y/t9anh ki0mt9+advULQ0IUl+zLj7ZZjd/up+gs0vvY2ETkp+6KXHxrVxuHrJ0svzbtGkaL5bxl80XLMDH6 zB83v1/NH5e3DYs/02bVjk9nD5Neh+REASA3C4WaJ8phNn/I9TFHIX0twvIgnBn08dPnm6vPNztt BDNoI6AKL7WxdBYYGly6qX5+G3caUn2rGJxm7b2KOJD+7rqw3WjlWwUPTU+0FHl8pjOVZWOBqUgU MkkqHZE17Z08hs8o2RWtX+tG1me6UtoMBheOEt7tdAU5vgg1o7hBB7GTo6RM0NwaJJHIw1lZDNDS CzbN/hU65rmRbHxaJWOEQZ52SQ4VMkbgbNBYRna1y0Fh3bDTrwoJDSj3CbJDuxoJbbjGB8rFyy4H 40m9JEXml8MzXnNXWo9XQ0IubNjxcnb/NHn81jTs42zZPE3u73NkWfKqFFdGDLnyt9/3UaW0A6qU eNi+mipB45CK/ytVQpEUpOaBdlFHChI9KDz9jqdKKdCTND52ORjw/I1DupCQF+fSkeQxI94nmcMW 0F3qhNyp+/nCOUSxxSdGpnAGv7aHYl9GlkOHFb3ckmWcx2uPvmPJMqzJMkq9qKSROri1LulhLVlq lOGw068KslRIekSWQ7sasrRcgzGZePmbzwTcJEbHdgdvvhpO0yhTDM7s+rVVkBf4eAql3WCGkTDL qJO0sALq+6HDiuNNSsWlwrKiRFLYSbwNpfVrlNEkxbDLTFyWbbale8eVgs0JwTzxD54V4iKtnRwC F9pJdvPUBRD04+F+WBxD6scwStcQww3QAz6xw+wvJY6kSTPt4xvs3Zpw8V9T/I+kaevv7TrVNOcu cXr1+AUXGHs/nS6b1Wp3ssnXWedhk/Y6Z9DKCUQjhG0OfXJ1T+BQARjoLinUHwQ/kBH82tsK0sPd yE3ARRB5HKjt7BwgmXtH+ItSeSnvUbLIeyPpQGUGsnTZasR5kHgebBIBd4ltFmFnJNcOURU4ewws EVLSmCTKsbBEBgtGJZm+EpYGt2twidO/CZY5Qdo/AXKtU2oj9CRii2BJKm4vM8CxzIDOHUF1GOXY JzD48oTaoY9XP4EiOCVO/54nKE+BEXg1qk7xMukvUVUb+bOnYBjlpVMQZfqzpmDodP8TFF9AeZQa Tjq3/wWKykBLrqTuZa5SRM3YmYEgreRmkv42djig5uydgUIHt7JLM/kJ1LzN2edeFzyqEe91HLtO xGoO3iVZ14hYy4N3Sd9rRawKXGoUsfuDHhCxkjuPIjayqxGxmjtt0jetELGoObxJiiyKWJlVj1us KtSHSndHC7LBBTPWoJTbh1V5+BRFeUQXZeRyIGQPUTKs+SDK5ZVoXY1AjaSA8almVegDx4W3Lkm/ KD4UIOWDTcquRZ9FnarT0vugPjfgymocMgOxXQX6nONG62yRWfR52v06KbKMvqJcACDMdA/uJGUI 6iVEieyv8AwZOjwr1/WsKKJEXoK8IlBAY9FGQBLrGa9yBLIOqiTZLcmNYbVlnqSuC1qRA7NaoGps MNj9EQ+QJM6UNSEyq+FIZBJrMvXlQWqBW2Hi+soYDSWMohxxpBjXklYEurSQfy+HIH2c1oAUHdm1 9Bx6HKA0y9XScx9o2oeGLyZISrYDHPKjHp9W8iMmsebHKPsyPyqJspD4cWhXzY+KtiVkgh7gR0vb UsZ2NfxI76dtrsg8PyKPe52ApYy97C7dYg95zRCvdVzBNs8ojibIAMiPVsUOB9DLmTmkRxI5cR41 wOtdZ+fLO5xS0LHzA/ITu18DVPAeac6ntRbpEQICSnuI7WqBCgqZzoZM0DxDguFOWB/bVQBVeeS6 nQft4+UWL8lWWMvdoV0WqKzMTR1SFcp+PHE2pHt+N5k9sI+frv94f/0rG2M9eIX92B6g3lyyxf9o L7feNrEgAL9X6n846ttKWcSc+6FPuVRtpLqNUlu7D3khhiTIMViAt6pW/e87mGBzMMdgJ2upSmNl Zs7cvwnni7gszgiwz+T+VxkXd3/094gbGxvLCvGfyZcrcrUoi1ohKcP8MS43JbTKs5Jkq5Lgs6pP tq6/L7J1Po+J/Yniorx7n6RhmWSpKx7OId+8SmhPgJKteHyfTW9m071wSH5MOAbtcpwCTO+CMZhB 5F7JtLElXx/BTfzu3ncjuB19g2nl1fWi+d7oewlbs8mGDxMjPV0NMUvjbvYx1xLB5ehREKb7lJex F5dP4Jx+jrVbVGtXqkDqU6PCfM+APrgQRsGI4Z4UOAcshSOONdRpjOy+40gSGWQvigTHcX3vubsf yJHELHA8q867R8CLjwvQV524j90JDGNF92I8gpop4r3seD8Gm4XHMakue86dgKMKfNFx0r0Ttulj g9XqM2wvU4/mqy+XN+RHnP8T5+QySx+Sx+1KdunBq1MZTLGlh0yS55/hehG7dpXvvPZenkU1x/vC r2dzsXnRQGQBMUgrW3BXPe5l63HQ0hZLojgtk4cEo7BsHPGWOP/LfD1fePNs+bF/NgyxIlWIEkjE lZEoSovDLuHU50IbS2rrETi5Gn8aLJC21HoVhWV82JoAjxnlsObsPsE9nynbWlH+eo5JGB22p5CO qsLptcdd9YEQzxheOG2pp2zuyIcbbJuE4BEiONRro1jfp7hKAUEcJPYbcp9P8JtlWCwIxc5t/vn/ nmpOKOxIsGdlHqaPuJ3bZimqtn7nvsvDof6mHFVoCpZJhATkJhJlS4SegTRxTzFlq9kVoautFPqp kPcssTRcdijkg9VUH072EUnbcCpe62NbzZ8v29m4enrrYluqcvGwrWap7xs7vNMVVhfuG0usnovF Dq/cFwDgHSegJ1KDHQeMYovzTngoSKQ5j1J0Rx72GLDTAXACWwrOdoQxdLdQajwlqbHSO/RptAvX nKzay+B1ZmmXVXaq09QbcopV7V5FpS3+cbd3ncS6dQrfphnrq9kcyb3K696nPRNAO9qFDcYTcIhy JvtM1zNwoF3Ak6DA1rMrYZd57DIGypbajFbrY83ZHg8PuOVXwalH+e8WAblWVyMHmnmKc+0gIDIJ o6RwXpmDJANYUEwLcTTJWIK78LqRtCYZS6xNMrUbb8IxIKQHXJgjQcYSG08yltgxKNNvb5BlLLHj YKbf4iDNWGKvwBngEikWt0svzui3xhlgeHppKQ/jTHW5+NbviDenrvpKXODYfd2mb2sZDzNtqf+N ZQAMIqLir/WwrWY0y1hS41lm39golrHEGpZpr273aFWIMzixO8GyoOTs5ARUpaDUUbTR4gZX4l3V tbWLf2S47gX1EUCAXSXgVCIwuHKk7uXnY4CgrWY0D7SF3hIHNEW+0qaLA84ub+QwlYCzfCM3SZ5/ hutFHJPrFBPwEM7jwn7D+LriwtPg16Ual09+7d/XJF2QOJ2Hq+BT+RTn1cQmX/4Koygnvh8IP9AX wdV5cHUR0EtHZQ1ll+GNq/xuQSeVqcpO0B9HST0FilrSN+v752ROzlEqLrAcL+ZhUQbSeHjm4dLF JBHEpWIRtNOGN2D74Ywqie2LH7Q1jd61HHGhzZbwcEwZgI4jsxtycfv9/Ory/MeU3M6+fbv+9plM Zl+n15tvyGQ6C0BU1idxmSfzABxxHDIP2GMAomP+9m+ywskfl0UgKBiBABHneZYXgU+iPFut4gj/ l+Fwy9dp9eVDjoM18Pcf8Wn67j8BBgCIn/aEDWVuZHN0cmVhbQ1lbmRvYmoNNzcgMCBvYmoNNDAz OCANZW5kb2JqDTgwIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODEgMCBS ID4+IA1zdHJlYW0NCkiJxJddbxu3EobvDfg/8NK9CMvhN/dOdoPWiG0JPgraCwOFLG9OdKJoVWld JP31Z7iKZC53KSpSjNqwsdKSM0Ny5uE7jPz3DMiMnP18X84n9ezv8qqaV6vZ57JezaZkNTu7HJ/9 PIY/gXAmLRl/OAPGKBeEjP8hjDImHGH+d/MInHLjFDGGU8UYTvh8dkF2P+M/yHIy/VTW60Iz60AJ Uq5W1WpdMPK0qpbL8gmfqr/xy+eF/3I6Wa1m5apgP43/5z03bi/It09UQC4OLajgwKM4ptV8PlvP KvRhnZOk/vLXc/lczstFgWb7fXGZ86UkZRZU5Ov+D/L4tS7XhTQccM2Gk4cLqTB4cvv48FOzKZsB wKyVSmrlRwATljLycO4HJSJSuYikpI6BiyK6XtR+g5d1AUAuJ+uSTJ6eVuUaN/wLSHRzW36uVl8L ydALa+9H1xnmBWUCTNvbm90RmeQ8TbUB3Z638Slse8XfsWSuqbTcNMbK+iNslnwzW3wi5WI6WRZv 64/lalHWhPz2u183YaxgthhAwa8KDoVWid3mOddgqGAi2uyZd+X9FOA4BW0pcIXrwMAup5N1HX2t du5S+wZO4r5xiPzdTtafCpxPt39HpzHzsQgZreP9iFzeDwe/XA3+Myb37+/uru9+Jbfvb8bXzTfk dvy+AOXd3TbsKOBI/9pZaq2I0XH/gg4JggsLW3SIfnR8WE0+l4VIRJEDmLaOGiZjcIzDKDgoy7dR yKMAxm02DkYVlzFUAoAhUVwLYFvbJl0rkioR2U5iL1dxWMO4DBlDZoc9iy6ME3gXPFxYnORi7AnG mVISCfJwwa2HHg44T0Ivmz8a64mpuA73Qo/Fq39xl7thtBRUW914m1dbbwFvbqrpZE5uqmr5iJmT WJTOeRF4ZEzHRRnAhRuKcygEJPCfU6eag5lGGgmu4ypECtwMh6PLwdW7HQQ2pY/7oPfVvnPUZo8O NN6gJii67KlznCoc9EwNgJGVGRtWpPYqmwJ4kzlm4hodf0cAOZ2T2znlDDX4lMYECxlx7N2gsDwl wjlV68JZX+aCWvIuKvL2m1S15XCoDKY43yxzuVyyTrWNqtmi3i9YnKLgNG/Z2smVFO1wf63Q0JpU V/sdgVdGRtl+T+kLHtPJgDKtac26yGhV7ZxSfJMwIJGySrZXiKmQOPRkHNs91wwvZLeHPbGwGWX2 hfsTwBujZbnZmL7Bfuex9WgNrhODBT4oaXosN2WUpJ7gVDup2/NGwcr0ZmUdlfWi2L6XGkoBKgzX Q9jR8PpuPGz+7yB7Nxzcj47SW9k4MFsU3sFpvYVawcjTEJqTW0pgn6bYPoQyhSe0C2JrGdLyhFMG eGZt069DXxRUAOxQ+qY0adYNYKMkIElfbqQz4JzXUZivsc6ykmsUR/613Xafx3JYOk0V8C2H+Skc Dm0dzOFw0sEc7vWU53A4LeDw8USVFjs3wV+BqC3LOaK2BueI2rV8GFFb80Kimh9OVGnQruKvTtRc nUpcnwMBaaIChsoNOwmpub5MKuxghdiDVJDY9wAEUeS3Go+VCZ8OofXXYKpUCAElTmVqdpckUAEy yVTn8KCU9dBEXnWYyq0ygL1P07saTmUz4OH8aK5yL93UlqvyJK4Gtg7najDpcK72eTqAq8G0H8NV EN7ya3A1tJzlajg4y9WO5f3afsfVcF7IVdvL1d35pzKQK0Elc1FAJ+EY0wOl478ucAUWhFB6D46V QVyfJHAheV7bIKxGiaj3CVzHcf8zQZxKVWE0Skh9AlWdoy7rRRtqlOlANXuDCkOVs5GBF3kLWivX oFZR15G3XtwCNPIWa6RP3h7OYSF9a2E3RXA7eZqtqwW5XtTl6sNkWq5TeM8BSnDs+YTbpGJZf2Qd vr+tP5Yrzyvy2+8eWYSxgkHBRHHFCqfxwjnyohP4oJSLE/CFjf2c0hxhYHh7+uj5cT6bkgFOK9dr Qi6nk3VdaEelxYpHDpk+XSdboQtu8JAd/qCz8dPZd+grwbCj831OByyX98PBLw0+tlg5BigZ99xh tydZj2TYlrJThkt5CE9y1zJHGGuEU9vp0RTiFjtIzXSaQoaDU/pACqVyMVddqKiosTGQAwiBDCmE No9Memx4qZIQC4KdugPhHDCH8u/hAm+Ab/ItgIrG/cDWT+F7jQfQq+520ehcNApbIQ3xhdhgZfW8 rAvU4peTddnUIxZWwb6UMl774bDhAtsQydUWNnAQbN6yQl4Vg0EhOa7+yA6Ic+wONI8rtE+IfZMr G4S0v1ZtijycNxxJ5UI+Jq9+RFy2P4wa2aQH7DSkiGsv7AoZ6i4OOW5sb+EUMhhQazDLWg5PEi+c +WOJq2gcAk/496dplxx3fXI4K+MwUtrleGqARQUsZVynO2pwxbViDjwVULN1pQhHiWUMUs4PsGjd DziP5chu4blwDOporWJcvmBDdajBktSArDeFQlWqTenOq623gBo31XQyJzfb5pDKZPpgJkqHplo2 q+UjZs2RCAWJ+hV1Xhos2IThHBp2QP5zKheySYeS1KC07FLjZjgcXQ6u3u2gsUGF9hV3asvi+eeb wyQquDmtX8kuGxxeVWZPyR8QQabg83sPeI7WxNsQFnxOP6EmBRRjkamAEqnYsomIg5zsaJgXRmjB nW1aFYPJ+C4CRPdt6pbPXSvY6yhrN6W1XC5Zp1xH1WxRh9a7tpzCOwCLKrT1Jre1zlCLaqY1qa72 OwImKTPK9ntKKxqmsQtRpjWtWRcZraq6woxIHGNOIxnsJKTbg5NYp4wyC+R+K5GIoeE3/a2VR5UV eM2EY+vEWIEPnggdu/uvTsGxfZC6NW0UrEptVtVt1pQ6DhxeJWvXg8vR8PpuPGz+74h5Nxzcj0Kx tbulUufGAesFgLf8HCzRcthV2B3FmjWArnK4Le4U7GaVllTUYpGksauME+zQ/iyltHJSWWDXZNg+ 7oYIFccKcuyGHCQJipeuxfFeQ2HZ647GMmCcYRuIfpNg3UDejs/+L8AAfvgxMA1lbmRzdHJlYW0N ZW5kb2JqDTgxIDAgb2JqDTIyNTYgDWVuZG9iag04MiAwIG9iag08PCAvVHlwZSAvTWV0YWRhdGEg L1N1YnR5cGUgL1hNTCAvTGVuZ3RoIDEzNDAgPj4gDXN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPScn IGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnIGJ5dGVzPScxMzQwJz8+Cgo8cmRmOlJERiB4 bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnCiB4 bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4KCiA8cmRmOkRlc2NyaXB0aW9u IGFib3V0PScnCiAgeG1sbnM9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nCiAgeG1sbnM6 cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJz4KICA8cGRmOlRpdGxlPk1pY3Jvc29m dCBXb3JkIC0gRG9jdW1lbnQxPC9wZGY6VGl0bGU+CiAgPHBkZjpDcmVhdG9yPldpbjJQREYgaHR0 cDovL3d3dy5kYW5lcHJhaXJpZS5jb208L3BkZjpDcmVhdG9yPgogIDxwZGY6QXV0aG9yPnNjb3R0 PC9wZGY6QXV0aG9yPgogIDxwZGY6Q3JlYXRpb25EYXRlPjIwMDQtMDItMDlUMTA6MzA6MTJaPC9w ZGY6Q3JlYXRpb25EYXRlPgogIDxwZGY6UHJvZHVjZXI+UERGbGliIDMuMDMgKFdpbjMyKTwvcGRm OlByb2R1Y2VyPgogIDxwZGY6TW9kRGF0ZT4yMDA0LTAyLTA5VDEzOjI3OjQzLTA2OjAwPC9wZGY6 TW9kRGF0ZT4KIDwvcmRmOkRlc2NyaXB0aW9uPgoKIDxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycK ICB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycKICB4bWxuczp4YXA9J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nPgogIDx4YXA6VGl0bGU+CiAgIDxyZGY6QWx0PgogICAg PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5NaWNyb3NvZnQgV29yZCAtIERvY3VtZW50MTwv cmRmOmxpPgogICA8L3JkZjpBbHQ+CiAgPC94YXA6VGl0bGU+CiAgPHhhcDpBdXRob3I+c2NvdHQ8 L3hhcDpBdXRob3I+CiAgPHhhcDpDcmVhdGVEYXRlPjIwMDQtMDItMDlUMTA6MzA6MTJaPC94YXA6 Q3JlYXRlRGF0ZT4KICA8eGFwOk1vZGlmeURhdGU+MjAwNC0wMi0wOVQxMzoyNzo0My0wNjowMDwv eGFwOk1vZGlmeURhdGU+CiAgPHhhcDpNZXRhZGF0YURhdGU+MjAwNC0wMi0wOVQxMzoyNzo0My0w NjowMDwveGFwOk1ldGFkYXRhRGF0ZT4KIDwvcmRmOkRlc2NyaXB0aW9uPgoKIDxyZGY6RGVzY3Jp cHRpb24gYWJvdXQ9JycKICB4bWxucz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8n CiAgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJz4KICA8ZGM6dGl0 bGU+TWljcm9zb2Z0IFdvcmQgLSBEb2N1bWVudDE8L2RjOnRpdGxlPgogIDxkYzpjcmVhdG9yPnNj b3R0PC9kYzpjcmVhdG9yPgogPC9yZGY6RGVzY3JpcHRpb24+Cgo8L3JkZjpSREY+Cjw/eHBhY2tl dCBlbmQ9J3InPz4NZW5kc3RyZWFtDWVuZG9iag14cmVmDTAgODMgDTAwMDAwMDAwMDUgNjU1MzUg Zg0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwMDg2IDAwMDAwIG4NCjAwMDAwMDAxNzUgMDAw MDAgbg0KMDAwMDAwMDM5OSAwMDAwMCBuDQowMDAwMDAwMDA2IDAwMDAxIGYNCjAwMDAwMDAwMDgg MDAwMDEgZg0KMDAwMDAwMDk1NiAwMDAwMCBuDQowMDAwMDAwMDEwIDAwMDAxIGYNCjAwMDAwMDEw NjEgMDAwMDAgbg0KMDAwMDAwMDAxMSAwMDAwMSBmDQowMDAwMDAwMDEyIDAwMDAxIGYNCjAwMDAw MDAwMTQgMDAwMDEgZg0KMDAwMDAwMTI5NSAwMDAwMSBuDQowMDAwMDAwMDE1IDAwMDAxIGYNCjAw MDAwMDAwMTYgMDAwMDEgZg0KMDAwMDAwMDAxNyAwMDAwMSBmDQowMDAwMDAwMDE4IDAwMDAxIGYN CjAwMDAwMDAwMjQgMDAwMDEgZg0KMDAwMDAwMTUwMSAwMDAwMCBuDQowMDAwMDAxNjQ4IDAwMDAw IG4NCjAwMDAwMDE3NDAgMDAwMDAgbg0KMDAwMDAwMTg0NyAwMDAwMCBuDQowMDAwMDAzMTk2IDAw MDAwIG4NCjAwMDAwMDAwMjUgMDAwMDEgZg0KMDAwMDAwMDAyNiAwMDAwMSBmDQowMDAwMDAwMDI3 IDAwMDAxIGYNCjAwMDAwMDAwMjggMDAwMDEgZg0KMDAwMDAwMDAyOSAwMDAwMSBmDQowMDAwMDAw MDMwIDAwMDAxIGYNCjAwMDAwMDAwMzEgMDAwMDEgZg0KMDAwMDAwMDAzMiAwMDAwMSBmDQowMDAw MDAwMDMzIDAwMDAxIGYNCjAwMDAwMDAwMzQgMDAwMDEgZg0KMDAwMDAwMDAzNSAwMDAwMSBmDQow MDAwMDAwMDM2IDAwMDAxIGYNCjAwMDAwMDAwMzcgMDAwMDEgZg0KMDAwMDAwMDAzOCAwMDAwMSBm DQowMDAwMDAwMDM5IDAwMDAxIGYNCjAwMDAwMDAwNDAgMDAwMDEgZg0KMDAwMDAwMDA0MSAwMDAw MSBmDQowMDAwMDAwMDQyIDAwMDAxIGYNCjAwMDAwMDAwNDMgMDAwMDEgZg0KMDAwMDAwMDA0NCAw MDAwMSBmDQowMDAwMDAwMDQ1IDAwMDAxIGYNCjAwMDAwMDAwNDYgMDAwMDEgZg0KMDAwMDAwMDA0 NyAwMDAwMSBmDQowMDAwMDAwMDQ4IDAwMDAxIGYNCjAwMDAwMDAwNDkgMDAwMDEgZg0KMDAwMDAw MDA1MCAwMDAwMSBmDQowMDAwMDAwMDUxIDAwMDAxIGYNCjAwMDAwMDAwNTIgMDAwMDEgZg0KMDAw MDAwMDA1MyAwMDAwMSBmDQowMDAwMDAwMDU0IDAwMDAxIGYNCjAwMDAwMDAwNTUgMDAwMDEgZg0K MDAwMDAwMDA1NiAwMDAwMSBmDQowMDAwMDAwMDU3IDAwMDAxIGYNCjAwMDAwMDAwNTggMDAwMDEg Zg0KMDAwMDAwMDA1OSAwMDAwMSBmDQowMDAwMDAwMDYwIDAwMDAxIGYNCjAwMDAwMDAwNjEgMDAw MDEgZg0KMDAwMDAwMDA2MiAwMDAwMSBmDQowMDAwMDAwMDYzIDAwMDAxIGYNCjAwMDAwMDAwNjQg MDAwMDEgZg0KMDAwMDAwMDA2NSAwMDAwMSBmDQowMDAwMDAwMDY2IDAwMDAxIGYNCjAwMDAwMDAw NjcgMDAwMDEgZg0KMDAwMDAwMDA2OCAwMDAwMSBmDQowMDAwMDAwMDY5IDAwMDAxIGYNCjAwMDAw MDAwNzAgMDAwMDEgZg0KMDAwMDAwMDA3MSAwMDAwMSBmDQowMDAwMDAwMDcyIDAwMDAxIGYNCjAw MDAwMDAwNzMgMDAwMDEgZg0KMDAwMDAwMDA3NCAwMDAwMSBmDQowMDAwMDAwMDc1IDAwMDAxIGYN CjAwMDAwMDAwNzggMDAwMDEgZg0KMDAwMDAwMzIyNSAwMDAwMCBuDQowMDAwMDA3MzQxIDAwMDAw IG4NCjAwMDAwMDAwNzkgMDAwMDEgZg0KMDAwMDAwMDAwMCAwMDAwMSBmDQowMDAwMDA3MzYzIDAw MDAwIG4NCjAwMDAwMDk2OTcgMDAwMDAgbg0KMDAwMDAwOTcxOSAwMDAwMCBuDQp0cmFpbGVyDTw8 DS9TaXplIDgzDS9JbmZvIDMgMCBSIA0vUm9vdCAyIDAgUiANL0lEWzxlMjEyMjM1M2U1OGVlMWQ2 MWVhODE1NTJmODY5Y2I0Mj48ZTIxMjIzNTNlNThlZTFkNjFlYTgxNTUyZjg2OWNiNDI+XQ0+Pg1z dGFydHhyZWYNMTExNDQNJSVFT0YN ------=_NextPart_000_0003_01C3EF10.9B7272B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 14:40:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06493; Mon, 9 Feb 2004 14:40: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 1AqHGD-0002nE-7t; Mon, 09 Feb 2004 14:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHFS-0002lC-Mk for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 14:39: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 OAA06427 for ; Mon, 9 Feb 2004 14:39:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHFP-0001rh-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:39:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHET-0001mV-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:38:13 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AqHDX-0001dw-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:37:15 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2004 11:36:12 -0800 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 i19JaaxN013716; Mon, 9 Feb 2004 14:36:43 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFX82462; Mon, 9 Feb 2004 14:36:35 -0500 (EST) Message-Id: <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Feb 2004 14:36:20 -0500 To: Harald Tveit Alvestrand From: Ralph Droms Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Cc: Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org In-Reply-To: <2435506122.1076323711@localhost> References: <000801c3ef35$831e44d0$6401a8c0@BVolz> <000801c3ef35$831e44d0$6401a8c0@BVolz> 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.0 required=5.0 tests=AWL 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: , The alternative method for configuring SNTP and NIS would be...? - Ralph At 10:48 AM 2/9/2004 -0800, Harald Tveit Alvestrand wrote: >--On 9. februar 2004 12:52 -0500 Bernie Volz wrote: > >>And, DHCP is really the Dynamic Interface Configuration Protocol. Why? >>Because everything we do is INTERFACE specific. Perhaps, even more >>correctly, would be to say it is the Dynamic Interface and Transport >>Configuration Protocol (because we're also IPv4 or IPv6 specific). > >Then stop trying to configure SNTP and NIS. > > > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 14:45:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06762; Mon, 9 Feb 2004 14:45: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 1AqHL5-0003Bu-12; Mon, 09 Feb 2004 14: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 1AqHKM-0003AL-2r for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 14:44: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 OAA06699 for ; Mon, 9 Feb 2004 14:44:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHKJ-0002Jb-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:44:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHJO-0002F7-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:43:19 -0500 Received: from mail.gmellc.net ([69.3.229.106] helo=mail.gmellc.com) by ietf-mx with esmtp (Exim 4.12) id 1AqHJB-0002AZ-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:43:05 -0500 Received: from pauljebe (unknown [192.168.8.3]) by mail.gmellc.com (Postfix) with SMTP id BE08040C0D6 for ; Mon, 9 Feb 2004 14:42:30 -0500 (EST) From: "Gregory Malsack" To: Date: Mon, 9 Feb 2004 13:39:43 -0600 Message-ID: <000601c3ef44$77cd8c80$0308a8c0@pauljebe> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: 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] Clients Report of the DHCP Server Address 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 All, Here's another one for you. most times when DHCP is working properly, doing a ipconfig /all on a windoz computer will inform me of what the dhcp servers address is. however sometimes, i don't get an address from the dhcp server properly, then the dhcp server address in my ipconfig list is either 255.255.255.255 or 127.0.0.1. Can anyone explain this? --------------------- Gregory Malsack President Gregory Malsack Enterprises, LLC 262-650-0059 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 14:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07379; Mon, 9 Feb 2004 14:59: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 1AqHYa-00041K-Vc; Mon, 09 Feb 2004 14:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHXr-00040b-6G for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 14:58:15 -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 OAA07317 for ; Mon, 9 Feb 2004 14:58:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHXo-0003Ts-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:58:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHWr-0003Pi-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:57:14 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AqHW0-0003Hn-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:56:20 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i19JtX8m013621; Mon, 9 Feb 2004 20:55:33 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i19JtYkj026683; Mon, 9 Feb 2004 20:55:34 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 9 Feb 2004 20:55:34 +0100 From: Stig Venaas To: Ralph Droms Cc: Harald Tveit Alvestrand , Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <20040209195534.GC26570@sverresborg.uninett.no> References: <000801c3ef35$831e44d0$6401a8c0@BVolz> <000801c3ef35$831e44d0$6401a8c0@BVolz> <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> User-Agent: Mutt/1.4.1i 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Mon, Feb 09, 2004 at 02:36:20PM -0500, Ralph Droms wrote: > The alternative method for configuring SNTP and NIS would be...? Right, I don't know any good alternatives, except DHCP. So we really need DHCP to configure host parameters, not just interface parameters. If it learns host parameters from different inter- faces (or v4 and v6), we have a problem. There might be some administrative solutions to this. I think I'll ignore the multiple interfaces issue, it has been there forever. Then regarding v4 and v6. If all hosts are dual-stack, I would suggest the administrator only runs one version of DHCP, or at least let only one of them configure host information. In a network with both v4-only and dual-stack, it gets more complicated. You want DHCPv4 that can configure all the v4 clients need. Then for dual-stack, you would either repeat all host information, and configure them to ask DHCPv6 only, or you repeat no host information and let them query both. I'm not sure if these solutions are good enough. One particular issue is when you want to configure a dual-stack host with both a v4 and a v6 NTP server. I think that is a realistic and reasonable scenario. Should you query both DHCPv4 and DHCPv6 servers, get v4 address from one and v6 from the other and use both? Might be right thing in some cases, not in others. I think it's much cleaner if you can get both v4 and v6 addresses from DHCPv6 NTP option. This could either be done with mapped addresses (so v4 is embedded into v6), or I suppose made more explicit by having some type field saying whether the address is v4, v6 or something else. Perhaps TLV encoding... NTP is of course just an example here. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 15:17:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05934; Mon, 9 Feb 2004 14:31: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 1AqH7V-0001ni-Q6; Mon, 09 Feb 2004 14:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH6r-0001mk-Jr for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 14:30: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 OAA05897 for ; Mon, 9 Feb 2004 14:30:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH6p-000153-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:30:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH5p-0000zw-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:29:17 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AqH59-0000qy-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 14:28:35 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1FFD361BAF; Mon, 9 Feb 2004 20:28:04 +0100 (CET) Date: Mon, 09 Feb 2004 10:47:00 -0800 From: Harald Tveit Alvestrand To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <2435415211.1076323620@localhost> In-Reply-To: <1F64DC40-5B24-11D8-93AF-000A95D9C74C@fugue.com> References: <2427813621.1076316018@localhost> <1F64DC40-5B24-11D8-93AF-000A95D9C74C@fugue.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========B60FB089B024307FA6CA==========" 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 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: , --==========B60FB089B024307FA6CA========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks Ted! The hierarchy you describe seems to make sense to me - and no, I hadn't=20 realized that DHCPv6 worked that much differently from DHCPv4. --On 9. februar 2004 11:19 -0600 Ted Lemon wrote: >> - For "Host specific", make it easy for a host to figure out which set >> of parameters it uses, and let it stick to that set only. No mixing! > > Okay, but how do we specify this? I guess saying "no mixing" is pretty > easy, but I don't see how we can go beyond that, and I'm not sure that > just specifying that is going to result in reliable behavior - it's easy > to imagine a dumb DHCP client stubbornly making the wrong choice every > single time. simple - outlaw dumb DHCP clients :-) joking aside - you probably need some kind of mechanism to specify that you = keep on listening to the "same administrator as last time", and mandate=20 that a DHCP client has some way to explicitly switch administrators. This is very similar to what you have to do if you have secure DHCP using=20 administrator-related keying....... >> - Make sure that all "Host specific" parameters are able to specify >> values that make sense for both IPv4 and IPv6 > > I'm not sure we've been doing this, but I agree that it's a reasonable > thing to do. I'm sure you don't - since that's what the nisconfig DISCUSS was about... >> - In all the instances I've seen so far, declare that if you need an >> IPv4 address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) >> - no other changes needed. > > So are you saying that a DHCPv6 client should be able to acquire IPv4 > addresses, or just that when it gives the addresses of the DNS server, it > should be able to give the IPv4 addresses as well as the IPv6 addresses? The latter. > I can see a lot of problems with the former; in the case of the latter, > it makes sense, although I would argue that the server administrator > should be able to enable or disable IPv4 to IPv6 address mapping, because > I can imagine cases where you'd want it and cases where you wouldn't. Of course - a v6-only host should know that it can't use a v4 address, no=20 matter how it got it. But that isn't much of a pressing problem,=20 unfortunately.... apart from special-purpose devices, I think all hosts=20 will have to know how to reach a v4 address for many years to come...... >> I may now have repeated a proposal that was suggested and rejected 3.5 >> years ago - that's life too. But you asked...... > > It's good that you're asking these questions. I'm sorry for dumping a > pile more on you, but I am definitely interested in your answers. We > needed to kick 3315 out the door, for obvious reasons, but that doesn't > mean that it requires no further tweaking. Fortunately, I don't think > what we're talking about here requires any incompatible changes. Without knowing too much - I don't think so either - and thanks for=20 listening! Harald --==========B60FB089B024307FA6CA========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFAJ9WnOMj+2+WY0F4RAlrAAKDmiNX8panWIJcvvxvW/K8hTXM0NwCeI0C/ kS2hUC+lm3EgPTTQ7fSYba4= =c2u/ -----END PGP SIGNATURE----- --==========B60FB089B024307FA6CA==========-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 15:43:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10480; Mon, 9 Feb 2004 15:43: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 1AqIFB-0007PO-Ar; Mon, 09 Feb 2004 15:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIEX-0007Ot-LE for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 15:42: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 PAA10448 for ; Mon, 9 Feb 2004 15:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIEW-0007Lt-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 15:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIDa-0007HG-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 15:41:22 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AqID5-0007CX-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 15:40:51 -0500 Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id B3FA83A18DF; Mon, 9 Feb 2004 14:29:54 -0600 (CST) In-Reply-To: <2435506122.1076323711@localhost> References: <000801c3ef35$831e44d0$6401a8c0@BVolz> <2435506122.1076323711@localhost> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3E2D169E-5B40-11D8-93AF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Date: Mon, 9 Feb 2004 14:40:48 -0600 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.612) 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 On Feb 9, 2004, at 12:48 PM, Harald Tveit Alvestrand wrote: > --On 9. februar 2004 12:52 -0500 Bernie Volz > wrote: > >> And, DHCP is really the Dynamic Interface Configuration Protocol. Why? >> Because everything we do is INTERFACE specific. Perhaps, even more >> correctly, would be to say it is the Dynamic Interface and Transport >> Configuration Protocol (because we're also IPv4 or IPv6 specific). > > Then stop trying to configure SNTP and NIS. This is a non-problem. If the protocols are different between v4 and v6, they're different protocols, and shouldn't be represented by the same DHCPv6 option anyway. So the solution is to treat them that way. Practically speaking, if you have a dual-stack client, you're going to configure it with DHCPv4 and DHCPv6, so you can get your NISv4 address from DHCPv4. The way to write this in a standard if we decided to would simply be that the IP addresses for equivalent servers provided by DHCPv6 supersede those provided by DHCPv4. NISv4 and NISv6 aren't equivalent, so there's no problem. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 16:03:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11388; Mon, 9 Feb 2004 16:03: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 1AqIYW-0000ZM-W9; Mon, 09 Feb 2004 16:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIXk-0000UI-C6 for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 16:02: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 QAA11215; Mon, 9 Feb 2004 16:02:09 -0500 (EST) Message-Id: <200402092102.QAA11215@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, 09 Feb 2004 16:02:09 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-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: , --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 : Configured Tunnel End Point Option for DHCPv6 Author(s) : S. Park Filename : draft-ietf-dhc-dhcpv6-ctep-opt-00.txt Pages : 7 Date : 2004-2-9 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-ietf-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-ietf-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-ietf-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-9160442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-ctep-opt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-ctep-opt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9160442.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 16:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11549; Mon, 9 Feb 2004 16:04: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 1AqIZU-0000l7-R0; Mon, 09 Feb 2004 16: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 1AqIYY-0000ZW-9p for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 16:03:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11309; Mon, 9 Feb 2004 16:02:59 -0500 (EST) Message-Id: <200402092102.QAA11309@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, 09 Feb 2004 16:02:59 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-proxyserver-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 : DHCP Option for Proxy Server Configuration Author(s) : Senthil K Balasubramanian Filename : draft-ietf-dhc-proxyserver-opt-00.txt Pages : 7 Date : 2004-2-9 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). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-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-proxyserver-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-proxyserver-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: <2004-2-9160453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-proxyserver-opt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-proxyserver-opt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9160453.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 16:04:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11564; Mon, 9 Feb 2004 16:04: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 1AqIZV-0000mX-Ic; Mon, 09 Feb 2004 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIYo-0000ez-A1 for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 16:03: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 QAA11326; Mon, 9 Feb 2004 16:03:15 -0500 (EST) Message-Id: <200402092103.QAA11326@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, 09 Feb 2004 16:03:15 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-rboot-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 : DHCPv6 Support for Remote Boot Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-rboot-00.txt Pages : 6 Date : 2004-2-9 This document provides new DHCPv6 (Dynamic Host Configuration protocol version 6) options for clients, to obtain information about FTP (Trivial File Transfer Protocol) servers and bootfiles needed for booting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-rboot-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-dhcpv6-opt-rboot-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-dhcpv6-opt-rboot-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: <2004-2-9160506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-rboot-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-rboot-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9160506.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 16:04:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11613; Mon, 9 Feb 2004 16:04: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 1AqIZW-0000rG-Mv; Mon, 09 Feb 2004 16:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIYv-0000hG-SX for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 16:03:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11362; Mon, 9 Feb 2004 16:03:22 -0500 (EST) Message-Id: <200402092103.QAA11362@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, 09 Feb 2004 16:03:22 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-opt-extrboot-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 : The Extended Remote Boot Option for DHCPv4 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-opt-extrboot-00.txt Pages : 7 Date : 2004-2-9 Single TFTP [2] 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 [2] servers and bootfiles. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-opt-extrboot-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-opt-extrboot-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-opt-extrboot-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: <2004-2-9160516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-opt-extrboot-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-opt-extrboot-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9160516.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 17:07:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20524; Mon, 9 Feb 2004 17: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 1AqJYS-0008Gg-K6; Mon, 09 Feb 2004 17:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJXo-0008FZ-1f for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 17:06:20 -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 RAA20345 for ; Mon, 9 Feb 2004 17:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJXl-00040I-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 17:06:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJWc-0003kQ-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 17:05:06 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AqJUv-0003O7-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 17:03:21 -0500 Date: Mon, 09 Feb 2004 14:03:32 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200402092107.QAA11997@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3159180216_31712921" 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 Subject: [dhcwg] draft-yegin-eap-boot-rfc3118-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > 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. --B_3159180216_31712921 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FYI... Alper ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 09 Feb 2004 16:07:49 -0500 To: IETF-Announce: ; Subject: I-D ACTION:draft-yegin-eap-boot-rfc3118-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication Author(s) : A. Yegin, H. Tschofenig, D. Forsberg Filename : draft-yegin-eap-boot-rfc3118-00.txt Pages : 20 Date : 2004-2-9 DHCP authentication extension (RFC3118) cannot be widely deployed due to lack of an out-of-band key agreement protocol for DHCP clients and servers. This draft outlines how EAP-based network access authentication mechanisms can be used to establish a local trust relation and generate keys that can be used in conjunction with RFC3118. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yegin-eap-boot-rfc3118-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yegin-eap-boot-rfc3118-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yegin-eap-boot-rfc3118-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message --B_3159180216_31712921 Content-type: message/external-body; name="Attachment (Anarchie document).url"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItOTE2MDgxMC5J LURAaWV0Zi5vcmc+DQ1FTkNPRElORyBtaW1lDUZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC15ZWdpbi1lYXAtYm9vdC1yZmMzMTE4LTAwLnR4dA0N --B_3159180216_31712921 Content-type: application/octet-stream; name="draft-yegin-eap-boot-rfc3118-00.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItOTE2MDgxMC5J LURAaWV0Zi5vcmc+DQ0= --B_3159180216_31712921-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 17:11:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21169; Mon, 9 Feb 2004 17: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 1AqJcK-0000Rz-Hv; Mon, 09 Feb 2004 17:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJbZ-0000Mr-Rn for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 17:10: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 RAA20968 for ; Mon, 9 Feb 2004 17:10:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJbX-0004j9-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 17:10:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJaP-0004XF-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 17:09:02 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AqJZR-0004GY-00; Mon, 09 Feb 2004 17:08:01 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2004 14:07:32 -0800 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 i19M7TxH018828; Mon, 9 Feb 2004 17:07:29 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFX98943; Mon, 9 Feb 2004 17:07:28 -0500 (EST) Message-Id: <4.3.2.7.2.20040209170721.02848188@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Feb 2004 17:07:25 -0500 To: agenda@ietf.org From: Ralph Droms Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_11393482==_" 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 Subject: [dhcwg] Draft agenda for dhc WG meeting in Seoul 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: , --=====================_11393482==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please publish the attached draft agenda for the dhc WG meeting in Seoul. Thanks... - Ralph Droms --=====================_11393482==_ Content-Type: text/plain; name="agenda-out.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="agenda-out.txt" Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgICAgICAgICBESEMgV0cgYWdlbmRhIC0gSUVURiA1OQogICAgICAg ICAgICAgICAgICAgICAgMDkwMCBUdWUgMDMvMDQvMjAwNCAodGVudGF0aXZlKQogICAgICAgICAg ICAgICAgICAgICAoTGFzdCByZXZpc2VkIDAyLzA5LzIwMDQgMDU6MDQgUE0pCiAgICAgICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkFkbWluaXN0cml2 aWEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJhbHBoIERyb21zICAgICAg MDUgbWludXRlcwogIEFnZW5kYSBiYXNoaW5nCgpESENQIE9wdGlvbiBmb3IgUHJveHkgU2VydmVy IENvbmZpZ3VyYXRpb24gICAgICAgICA8VEJEPiAgICAgICAgICAgIDA1IG1pbnV0ZXMKICA8ZHJh ZnQtaWV0Zi1kaGMtcHJveHlzZXJ2ZXItb3B0LTAwPgoKVGhlIEV4dGVuZGVkIFJlbW90ZSBCb290 IE9wdGlvbiBmb3IgREhDUHY0ICAgICAgICAgPFRCRD4gICAgICAgICAgICAwNSBtaW51dGVzCiAg PGRyYWZ0LWlldGYtZGhjLW9wdC1leHRyYm9vdC0wMD4KCkRIQ1B2NiBTdXBwb3J0IGZvciBSZW1v dGUgQm9vdCAgICAgICAgICAgICAgICAgICAgIDxUQkQ+ICAgICAgICAgICAgMDUgbWludXRlcwog IDxkcmFmdC1pZXRmLWRoYy1kaGNwdjYtb3B0LXJib290LTAwPgoKQ29uZmlndXJlZCBUdW5uZWwg RW5kIFBvaW50IE9wdGlvbiBmb3IgREhDUHY2ICAgICAgRGFuaWVsIFBhcmsgICAgICAwNSBtaW51 dGVzCiAgPGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1jdGVwLW9wdC0wMT4KCkRIQ1B2NCBTdXBwb3J0 IGZvciBDb25maWd1cmluZyBJUHY2LWluLUlQdjQgVHVubmVscyBEYW5pZWwgUGFyayAgICAgIDA1 IG1pbnV0ZXMKICA8ZHJhZnQtZGFuaWVsLWRoYy1pcHY2aW40LXR1bm5lbHMtMDA+CgpSZXF1aXJl bWVudHMgZm9yIFByb3Bvc2VkIENoYW5nZXMgdG8gREhDUHY0ICAgICAgICA8VEJEPiAgICAgICAg ICAgIDA1IG1pbnV0ZXMKICA8ZHJhZnQtaWV0Zi1kaGMtY2hhbmdlcy0wMD4KCk5vZGUtU3BlY2lm aWMgQ2xpZW50IElkZW50aWZpZXJzIGZvciBESENQdjQgICAgICAgIDxUQkQ+ICAgICAgICAgICAg MDUgbWludXRlcwogIDxkcmFmdC1pZXRmLWRoYy0zMzE1aWQtZm9yLXY0LTAxPgoKUmFwaWQgQ29t bWl0IE9wdGlvbiBmb3IgREhDUHY0ICAgICAgICAgICAgICAgICAgICAgPFRCRD4gICAgICAgICAg ICAwNSBtaW51dGVzCiAgPGRyYWZ0LWlldGYtZGhjLXJhcGlkLWNvbW1pdC1vcHQtMDA+CgpNaWNy by1ibG9jayBJUCBBZGRyZXNzIEFsbG9jYXRpb24gV2l0aCBESENQIFByb3h5IFNlcnZlciBOYWlt aW5nIFNoZW4gICAgIDA1IG1pbnV0ZXMKICA8ZHJhZnQtc2hlbi1kaGMtYmxvY2stYWxsb2MtMDE+ CgpSZW51bWJlcmluZyBSZXF1aXJlbWVudHMgZm9yIFN0YXRlbGVzcyBESENQdjYgICAgICBTdGln IFZlbmFhcyAgICAgIDEwIG1pbnV0ZXMKICA8ZHJhZnQtY2hvd24tZGhjLXN0YXRlbGVzcy1kaGNw djYtcmVudW1iZXJpbmctMDA+CgpMaWZldGltZSBPcHRpb24gZm9yIERIQ1B2NiAgICAgICAgICAg ICAgICAgICAgICAgICBTdGlnIFZlbmFhcyAgICAgIDEwIG1pbnV0ZXMKICA8ZHJhZnQtdmVuYWFz LWRoYy1saWZldGltZS0wMT4KClZlbmRvci1TcGVjaWZpYyBTdWJvcHRpb24gZm9yIHRoZSBESENQ IFJlbGF5IEFnZW50IE9wdGlvbiA8VEJEPiAgICAgICAgICAgIDA1IG1pbnV0ZXMKICA8ZHJhZnQt c3RhcHAtZGhjLXZlbmRvci1zdWJvcHRpb24tMDA+CgpJUHY0IGFuZCBJUHY2IER1YWwtU3RhY2sg SXNzdWVzIGZvciBESENQdjYgICAgICAgICBTdGlnIFZlbmFhcyAgICAgIDEwIG1pbnV0ZXMKICA8 ZHJhZnQtY2hvd24tZGhjLWR1YWwtc3RhY2stMDA+CgpESENQdjYgSVB2NCBJbmZvcm1hdGlvbiBP cHRpb25zICAgICAgICAgICAgICAgICAgICA8VEJEPiAgICAgICAgICAgIDEwIG1pbnV0ZXMKICA8 ZHJhZnQtY2FkYXItZGhjLWRoY3B2Ni12NG9wdGlvbnMtMDA+CgpVcGRhdGUgb24gSVBSIGlzc3Vl IHdpdGggdHdvIGRyYWZ0cyAgICAgICAgICAgICAgICBSYWxwaCBEcm9tcyAgICAgIDE1IG1pbnV0 ZXMKClVwZGF0ZSBvZiBkaGMgV0cgY2hhcnRlciAgICAgICAgICAgICAgICAgICAgICAgICAgIFJh bHBoIERyb21zICAgICAgMTUgbWludXRlcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0KVG90YWwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDEyNSBtaW51dGVzCg== --=====================_11393482==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 17:12:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21317; Mon, 9 Feb 2004 17:12: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 1AqJdM-0000aa-5h; Mon, 09 Feb 2004 17:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJcJ-0000Rj-D8 for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 17:10: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 RAA21099 for ; Mon, 9 Feb 2004 17:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJcH-0004sl-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 17:10:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJbU-0004ih-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 17:10:08 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AqJaM-0004SL-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 17:08:58 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E7C2661C4C; Mon, 9 Feb 2004 23:08:25 +0100 (CET) Date: Mon, 09 Feb 2004 12:57:59 -0800 From: Harald Tveit Alvestrand To: Ralph Droms Cc: Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <2443273922.1076331479@localhost> In-Reply-To: <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> References: <000801c3ef35$831e44d0$6401a8c0@BVolz> <000801c3ef35$831e44d0$6401a8c0@BVolz> <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On 9. februar 2004 14:36 -0500 Ralph Droms wrote: > The alternative method for configuring SNTP and NIS would be...? vi (or emacs, depending on your religion :-) seriously, either everything you do is interface specific (and SNTP is out of scope), or some of the things you do are host-wide, and you need to admit that - in which case Bernie's out of line, and the chairs need to tell him so. Sorry 'bout that - it's a tough life! Harald > > - Ralph > > At 10:48 AM 2/9/2004 -0800, Harald Tveit Alvestrand wrote: > > >> --On 9. februar 2004 12:52 -0500 Bernie Volz wrote: >> >>> And, DHCP is really the Dynamic Interface Configuration Protocol. Why? >>> Because everything we do is INTERFACE specific. Perhaps, even more >>> correctly, would be to say it is the Dynamic Interface and Transport >>> Configuration Protocol (because we're also IPv4 or IPv6 specific). >> >> Then stop trying to configure SNTP and NIS. >> >> >> >> >> >> > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 18:23:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29279; Mon, 9 Feb 2004 18:23: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 1AqKk0-0002qW-KB; Mon, 09 Feb 2004 18:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKjV-0002pg-2u for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 18:22: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 SAA29143 for ; Mon, 9 Feb 2004 18:22:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKjS-00075Y-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 18:22:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKiT-0006wn-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 18:21:26 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AqKhb-0006lB-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 18:20:31 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2004 15:20:21 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i19NJvGq015742; Mon, 9 Feb 2004 15:19:58 -0800 (PST) Received: from mjs-xp.cisco.com ([161.44.65.244]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFY05224; Mon, 9 Feb 2004 18:19:56 -0500 (EST) Message-Id: <4.3.2.7.2.20040209174329.01cd5df0@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Feb 2004 18:19:34 -0500 To: Harald Tveit Alvestrand From: Mark Stapp Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Cc: Ralph Droms , Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org In-Reply-To: <2443273922.1076331479@localhost> References: <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> <000801c3ef35$831e44d0$6401a8c0@BVolz> <000801c3ef35$831e44d0$6401a8c0@BVolz> <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> 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.0 required=5.0 tests=none 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: , for a number of reasons (or accidents, depending on your point of view and memory), dhcp has focussed on transmitting configuration information. it has not developed a client api that would allow arbitrary applications to get at the information. it has not developed server configuration database schemas or apis that would allow information to be configured into arbitrary servers in a consistent way. because it has focussed on transporting configuration data, dhcp has become extremely widely deployed and is a very successful ietf protocol. perhaps some think that that sentence should read "in spite of that, ...". the ietf has blessed some configuration protocols which addressed some of the problems that dhcp has skipped, but none of those has been very successful. there are hard problems in developing an application-level dhcp api, and we've invested our time elsewhere. among the hardest of the problems is that all existing applications do not use the missing dhcp client api, so there's been little demand for it. and if we were to spend years developing one, we would also have to replace all existing applications before the api would be consistently used. unlike some working groups I could name, we have looked at that situation and decided not to do work that would have a very high opportunity cost and would not be worthwhile. a hypothetical dhcp client api might allow applications to register their interest in dhcp options, so that the dhcp client would ask for them as it interacted with the dhcp server(s). the api would also allow an application to retrieve the values the server(s) sent back. there are problems, like what to do when an option used by a running daemon changes its value. and should the dhcp client be willing to generate INFORMs initiated by any user-level application? some os's offer some sort of application-level support, some do not. it might be difficult to get dhcp clients deployed that offered a standard api, or it might be welcomed with open arms by os vendors - I don't know. here's what happens, mostly. someone approaches the wg, having identified some information that their application needs, and having found a way to get the information that they need into their version of an application on at least one os. we have pretty much limited our role to helping make the dhcp option sensible and configurable so that servers can distribute it to the clients who can use it. we expect that the clients who can use it will ask for it. we don't mandate that all clients start asking for it. and we don't make the folks who've approached the wg tell us how they do what they do. they're solving a problem they have, and we're helping them. in some cases, the options don't get used much. in other cases, distributing the information via dhcp, which is so very available, is so compelling and useful that other folks figure out how to use the data too. as we move towards first a dual-stack and then, eventually, a v6 world, it might be helpful to client implementors if we worked on an application-level api. but I'd sort of want to hear that from the client os and application vendors, so that there'd be some hope that the thing would actually do something useful. we have specified a consistent way to carry this nis information in a dhcpv6 message. we have not insisted that all nis application clients retrieve the information in the same way, or that all v6 dhcp clients export some sort of api that would make that possible. you can insist that we do so before allowing this particular option to move on, but I don't see much value in that. if the iesg wants us to develop a dhcp client api, that's another matter, and we should talk about that on another email thread. -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 9 23:24:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15261; Mon, 9 Feb 2004 23:24: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 1AqPRI-0000nh-On; Mon, 09 Feb 2004 23:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqPQx-0000nB-Jv for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 23:23:39 -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 XAA15245 for ; Mon, 9 Feb 2004 23:23:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqPQv-0001Pt-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 23:23:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqPQ9-0001Kb-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 23:22:49 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AqPPj-0001Dx-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 23:22:24 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i1A60lw3028544 for ; Mon, 9 Feb 2004 22:00:47 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [207.31.248.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Mon, 9 Feb 2004 20:21:54 -0800 Message-Id: <5.1.0.14.2.20040209231521.03cf9ba8@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Feb 2004 23:19:58 -0500 To: Ted Lemon From: Margaret Wasserman Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Cc: Harald Tveit Alvestrand , dhcwg@ietf.org In-Reply-To: <3E2D169E-5B40-11D8-93AF-000A95D9C74C@fugue.com> References: <2435506122.1076323711@localhost> <000801c3ef35$831e44d0$6401a8c0@BVolz> <2435506122.1076323711@localhost> 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.0 required=5.0 tests=none 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: , At 02:40 PM 2/9/2004 -0600, Ted Lemon wrote: >>Then stop trying to configure SNTP and NIS. > >This is a non-problem. If the protocols are different between v4 and v6, >they're different protocols, and shouldn't be represented by the same >DHCPv6 option anyway. So the solution is to treat them that way. What if the protocols are not different between v4 and v6? I don't know much about NIS, but the DNS and SNTP protocols (for example) are not different between IPv4 and IPv6, nor are most other application protocols. Most applications on dual-stack systems will not even be aware of whether they are running over an IPv6 transport or an IPv4 transport -- they just use TCP or UDP, and pass a version-independent IP address datastructure (that may have been filled in using DHCP, a DNS lookup, etc.) as a parameter. > Practically speaking, if you have a dual-stack client, you're going to > configure it with DHCPv4 and DHCPv6, so you can get your NISv4 address > from DHCPv4. The way to write this in a standard if we decided to would > simply be that the IP addresses for equivalent servers provided by DHCPv6 > supersede those provided by DHCPv4. NISv4 and NISv6 aren't equivalent, > so there's no problem. I don't know what you mean by "the IP addresses for equivalent servers provided by DHCPv6 supersede those provided by DHCPv4"? What is an equivalent server, and how would an application tell? Margaret _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 00:04:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16386; Tue, 10 Feb 2004 00:04: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 1AqQ41-0002Te-9o; Tue, 10 Feb 2004 00:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqQ3g-0002T9-8K for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 00:03: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 AAA16362 for ; Tue, 10 Feb 2004 00:03:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqQ3d-00051R-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 00:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqQ2e-0004wj-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 00:02:37 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AqQ1f-0004nG-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 00:01:35 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i1A6dxw3030422 for ; Mon, 9 Feb 2004 22:39:59 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [207.31.248.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Mon, 9 Feb 2004 21:01:06 -0800 Message-Id: <5.1.0.14.2.20040209233332.04345a40@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Feb 2004 23:55:47 -0500 To: Mark Stapp From: Margaret Wasserman Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Cc: Harald Tveit Alvestrand , Ralph Droms , Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20040209174329.01cd5df0@goblet.cisco.com> References: <2443273922.1076331479@localhost> <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> <000801c3ef35$831e44d0$6401a8c0@BVolz> <000801c3ef35$831e44d0$6401a8c0@BVolz> <4.3.2.7.2.20040209143602.027a1fd0@flask.cisco.com> 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.0 required=5.0 tests=none 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: , Hi Mark, I think that you have misunderstood the nature of Harald's "discuss"... At 06:19 PM 2/9/2004 -0500, Mark Stapp wrote: >as we move towards first a dual-stack and then, eventually, a v6 world, it >might be helpful to client implementors if we worked on an >application-level api. but I'd sort of want to hear that from the client >os and application vendors, so that there'd be some hope that the thing >would actually do something useful. > >we have specified a consistent way to carry this nis information in a >dhcpv6 message. we have not insisted that all nis application clients >retrieve the information in the same way, or that all v6 dhcp clients >export some sort of api that would make that possible. you can insist that >we do so before allowing this particular option to move on, but I don't >see much value in that. if the iesg wants us to develop a dhcp client api, >that's another matter, and we should talk about that on another email thread. Harald's two "discuss" positions (on the DHCPv6 configuration options for NIS and SNTP) do not mention an API, nor do they concern how an application requests or receives DHCP information within the host. They do question the fact that the DHCPv6 configuration options for NIS and SNTP do not mention IPv4, nor do they explain how a dual-stack node would obtain the IPv4 addresses of NIS or SNTP servers. Margaret _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 01:48:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19506; Tue, 10 Feb 2004 01:48: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 1AqRgf-0000HW-Bw; Tue, 10 Feb 2004 01: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 1AqRgK-0000Gg-T0 for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 01:47: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 BAA19499 for ; Tue, 10 Feb 2004 01:47:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqRgH-000727-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 01:47:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqRfF-0006vo-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 01:46:34 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AqReK-0006lV-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 01:45:36 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 406E161B92; Tue, 10 Feb 2004 07:45:05 +0100 (CET) Date: Mon, 09 Feb 2004 22:13:43 -0800 From: Harald Tveit Alvestrand To: "JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <2476616956.1076364823@localhost> In-Reply-To: References: <2427813621.1076316018@localhost> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On 10. februar 2004 14:43 +0900 "JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" wrote: >>>>>> On Mon, 09 Feb 2004 08:40:18 -0800, >>>>>> Harald Tveit Alvestrand said: > >> - In all the instances I've seen so far, declare that if you need an >> IPv4 address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) >> - no other changes needed. > > A couple of minor notes: > > - ::12.34.56.78 is NOT an IPv4-mapped IPv6 address (but an > IPv4-compatible IPv6 address). You should probably have meant > ::ffff:12.34.56.78. thank you! I really have no idea which of those two formats is the better one to use in this context, but have a strong preference that the drafts specify one, the other or "you shouldn't do this". Having users do (and expect) all three is the worst of all the outcomes.... > - if we really go with this approach, we should also consider > draft-itojun-v6ops-v4mapped-harmful-02.txt > which proposes "nodes SHOULD NOT generate packets that contain > IPv4-mapped addresses in any field" in a packet sent on the wire in > order to avoid confusion with API usages of IPv4-mapped addresses. > Though this is still an individual draft, there seems to be a > consensus on "no IPv4-mapped IPv6 addresses in the wire", at least > to some extent. I'll leave that to the IPv6 experts.... Harald _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 03:04:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04892; Tue, 10 Feb 2004 03:04: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 1AqSsE-0004kE-4O; Tue, 10 Feb 2004 03:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSru-0004iy-8W for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 03:03:42 -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 DAA04856 for ; Tue, 10 Feb 2004 03:03:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSrq-0005kh-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 03:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSqu-0005fv-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 03:02:42 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1AqSqB-0005bI-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 03:01:55 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1A81jf07650; Tue, 10 Feb 2004 15:01:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1A7wQe02265; Tue, 10 Feb 2004 14:58:28 +0700 (ICT) From: Robert Elz To: Harald Tveit Alvestrand cc: Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt In-Reply-To: <2435506122.1076323711@localhost> References: <2435506122.1076323711@localhost> <000801c3ef35$831e44d0$6401a8c0@BVolz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Feb 2004 14:58:26 +0700 Message-ID: <2134.1076399906@munnari.OZ.AU> 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Mon, 09 Feb 2004 10:48:31 -0800 From: Harald Tveit Alvestrand Message-ID: <2435506122.1076323711@localhost> | Then stop trying to configure SNTP and NIS. Harald, with all respect, this is plain stupid. DHCP isn't trying to configure anything. DHCP is a mechanism via which network managers can cause systems to obtain information, which they can then use to configure themselves. How the systems use that information is entirely up to them - you might believe that there's one "obvious way" (or obvious use) implied, but that's no more than something which might be done. Eg: for my systems at home, my DHCP server, for reasons not worth going into (well: I can't figure out how to reconfigure it, as all of its config info and documentation is in Japanese, and I don't read Japanese) sends a default router value of X - my systems see that X, and when that's what DHCP says the default router address should be, they set it to Y instead. Y works as a default router, and X doesn't. You might think that I could simply hard configure Y, but that doesn't work at all for mobile systems (there are a couple of laptops involved here) - when the systems get told something other than X as the default router, they configure the address they're told. If in some particular circumstance the information that DHCP could send to a node would make no sense, or not be able to be interpreted, by the node, then the DHCP server should be configured to not send that information. That doesn't mean that the DHCP protocol should have no means to send that information, that can be used in the other 99% of cases where sending the values does make sense - that would mean that the only thing left for DHCP as we know it to supply would be address, netmask, and (for IPv4) the broadcast address (maybe MTU I suppose). Everything else is "host" configuration (including the router addresses - as the default router implies a default interface as well as a default address out that interface). But do note, that in most cases (the odd case of a system with multiple interfaces connected to multiple admin domains, and using DHCP for all of them excepted) the fact that different information is received for the "same" parameter over different interfaces, or via different protocols, is really immaterial. Eg: take SNTP as an example. (I don't actually use DHCPv6 at the minute, I use autoconfig, but lets pretend I do use DHCPv6 for now - I do use DHCPv4). If I have a dual stack host with 2 interfaces, then I'm going to be receiving 4 different DHCP response, one for each protocol on each interface. On my DHCP (4 & 6) servers, I'm going to arrange to give the address of an SNTP server that's on the same link as the interface being configured (so systems can get the time, even if the router is dead). Obviously I'm also going to be giving the address of an SNTP server that can be reached using the same protocol as is being configured, as that's the only one I know the client will be able to reach. So, my client is going to end up with IF-1-6addr IF-1-4addr IF-2-6addr and IF-2-4addr as addresses for its SNTP server. The client now has to pick which of those addresses it should use - for SNTP it can probably just use all 4 of them (multiple servers doesn't net to hurt NTP, in fact, it is usually good) but let's assume that we're required to pick just one. Which one should we pick? You're certainly correct that the DHCP spec gives us no guidance at all. But does it really need to? What we want is to get the time after all. And last time I looked, the time was the time - and should be the same time, whatever server tells it to me. That is, if I have 4 plausible addresses, who cares which one I pick, any one of them is going to give me the time. On the other hand, I could also decide to get smart. Knowing something about SNTP, I know that I can query the servers, determine their status, who many peers they have, how accurate they believe their clocks to be, what their natural clock drift looks like, ... and having obtained all that information (measuring the RTTs to the servers while obtaining it) I can run some complicated formula and decide which SNTP server is going to be the best one for me to use. Which of those is appropriate is entirely up to the end system to decide, the DHCP server can't decide - it cannot really know how important the time is to the client in question, in order to know how much effort the client should take to get a really good idea of the time. Simply giving the client the raw data it needs to be able to make its own decision is as much as can be asked of DHCP, anything more than that would be too much. I'm not going to attempt to comment on how closely NIS fits into this kind of analysis (I know that most of the parameters that DHCP can configure, including default routers, and servers for most services around) fit fairly closely. But in my opinion, NIS would be better obliterated from the universe (DHCP included) than configured at all, so I have never cared whether it is really going to make any difference which particular NIS server I happen to pick (I would have hoped that they'd all give the same answers about a particular NIS domain, but who knows...). On the other hand, I also know that my opinion about NIS isn't shared by absolutely everyone, and that some people may be deluded enough to think they get some benefit from configuring NIS. So, I'm not about to object to having DHCP able to configure it - I just don't have my DHCP servers do that. My clients never have to worry about getting conflicting NIS information, as they never get any of it in the first place... If you have any real examples of cases where it really makes a significant difference which particular configuration is used, when the config received is different from different interfaces, and where the client isn't really the entity best placed to make the decision on which particular config it should actually use, then please demonstrate the problem - but more than just "I have to make a decision, and I don't know which one to make" - you also need to demonstrate that it actually makes a noticeable difference. Margaret Wasserman said: | Harald's two "discuss" positions (on the DHCPv6 configuration options for NIS | and SNTP) do not mention an API, nor do they concern how an application | requests or receives DHCP information within the host. | They do question the fact that the DHCPv6 configuration options for NIS and | SNTP do not mention IPv4, nor do they explain how a dual-stack node would | obtain the IPv4 addresses of NIS or SNTP servers. Yes, we know that. The topic was mentioned, and without dissent, it was suggested (with some explicit agreement, and no disagreement) that the solution to this was to explicitly state that DHCPv6 configures only IPv6 addresses of NIS servers (and others, though the draft in question is concerned only with NIS as I understand it, it is ...-nisconfig-... after all). The particular point of the discuss vote in the IESG will get fixed, no-one here is objecting to that (some of us see it as a pretty minor issue, that should have been obvious without explicit mention, but who cares, a few more words can't hurt much). Then Harald, in his capacity as a new/occasional member of the WG (I assume, that's what it sounded like) decide to argue for a different WG response. That's fine, he's entitled to do that. The WG is equally entitled to listen to his point of view, and then tell him that we don't agree, and that having DHCPv6 configure only v6 is the solution we believe is correct. From reading the messages in the past day or two, that seems to me to be the common view in the responses. The answer to "or do they explain how a dual-stack node would obtain the IPv4 addresses of" (anything at all) is that they use DHCP (SHCPv4) of course. Does that really need to be explicitly stated? The dual stack node isn't going to be a configured dual stack node at all unless it uses DHCPv4 to get its v4 addresses for its interfaces, now is it? DHCPv6 isn't going to be supplying that information. DHCPv6 isn't a replacement for DHCPv4, it is a new protocol that operates alongside DHCPv4, one for v4 information, the other for v6 information. If v4 addresses are being manually configured on a node, because it doesn't want to use DHCPv4, then its v6 SNTP and v4 NIS addresses can be manually configured at the same time, it would be laughable to suggest to someone that they should use manual config to configure v4 addresses, and then go ahead and use DHCPv6 to get the rest of the v4 configuration information, wouldn't it? Let's just go back to Ted's original answer when the question was raised, do (A), agree on that as WG consensus, fix the draft with that in mind, and send it back to the IESG. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 05:17:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10126; Tue, 10 Feb 2004 05:17: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 1AqUwv-0006Qc-8D; Tue, 10 Feb 2004 05: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 1AqUwg-0006Q4-7r for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 05:16: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 FAA10112 for ; Tue, 10 Feb 2004 05:16:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUwc-0004QD-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 05:16:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUve-0004LQ-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 05:15:43 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1AqUun-0004GK-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 05:14:49 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1AAEcf14565; Tue, 10 Feb 2004 17:14:39 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1AA9Qe01056; Tue, 10 Feb 2004 17:09:26 +0700 (ICT) From: Robert Elz To: Harald Tveit Alvestrand , Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt In-Reply-To: <2134.1076399906@munnari.OZ.AU> References: <2134.1076399906@munnari.OZ.AU> <2435506122.1076323711@localhost> <000801c3ef35$831e44d0$6401a8c0@BVolz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Feb 2004 17:09:26 +0700 Message-ID: <23984.1076407766@munnari.OZ.AU> 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 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 sent a long(ish) message with LOTS of typos... Apologies for those, I had a time deadline (something else to do at a fixed time) and so had no time to re-read my message and fix all my hopeless typing nonsense (as in, someone was bothering me to go do other work *right now* when I was just finishing composing my reply). I think the correct (intended) wording could be guessed most of the time though. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 08:48:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18439; Tue, 10 Feb 2004 08:48:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYFI-00049v-2m; Tue, 10 Feb 2004 08:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYEw-00048z-9L for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 08:47: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 IAA18401 for ; Tue, 10 Feb 2004 08:47:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYEu-0001lE-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 08:47:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYDw-0001fx-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 08:46:48 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYD2-0001b8-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 08:45:52 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i1ADjpOr009608 for ; Tue, 10 Feb 2004 13:45:51 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA02314 for ; Tue, 10 Feb 2004 13:45:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i1ADjn822429 for dhcwg@ietf.org; Tue, 10 Feb 2004 13:45:49 GMT Date: Tue, 10 Feb 2004 13:45:49 +0000 From: Tim Chown To: dhcwg@ietf.org Message-ID: <20040210134549.GC15972@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-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 Subject: [dhcwg] Renumbering Requirements for Stateless DHCPv6 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, There have not been any list comments on a draft that I wrote with Stig and A.K. after Minneapolis on the issue of how nodes using DHCPv6 only for non address configuration options should leanr ofconfiguration changes. http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt There has been a comment regarding the Reconfigure message (and lack of use of it?) on the list, though not in the context of this draft. There have also been comments that there are wider issues here, e.g. in terms of node use of DHCP(v6) servers when moving between networks. I would be happy to update the above draft to a -01 version if there are (constructive :) comments. Note that Stig will present this draft and a solution draft in Seoul. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 11:10:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25473; Tue, 10 Feb 2004 11:10: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 1AqaSX-0002z4-I0; Tue, 10 Feb 2004 11:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaRq-0002sA-6S for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 11:09: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 LAA25381 for ; Tue, 10 Feb 2004 11:09:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaRn-0007l2-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 11:09:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaR5-0007dm-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 11:08:31 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AqaQ7-0007UF-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 11:07:31 -0500 Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id A81301B2735; Tue, 10 Feb 2004 09:56:22 -0600 (CST) In-Reply-To: <5.1.0.14.2.20040209231521.03cf9ba8@ms101.mail1.com> References: <2435506122.1076323711@localhost> <000801c3ef35$831e44d0$6401a8c0@BVolz> <2435506122.1076323711@localhost> <5.1.0.14.2.20040209231521.03cf9ba8@ms101.mail1.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <36FAAA38-5BE3-11D8-93AF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Harald Tveit Alvestrand From: Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Date: Tue, 10 Feb 2004 10:07:24 -0600 To: Margaret Wasserman X-Mailer: Apple Mail (2.612) 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 On Feb 9, 2004, at 10:19 PM, Margaret Wasserman wrote: > What if the protocols are not different between v4 and v6? I don't > know much > about NIS, but the DNS and SNTP protocols (for example) are not > different > between IPv4 and IPv6, nor are most other application protocols. If we accept Harald's idea that the client should get its configuration from the DHCPv6 server and not the DHCPv6 server, then I think the simplest rule is to say that if the DHCPv6 server sends IPv4 addresses for a service expressed as IPv6 addresses, then those addresses are the ones that the DHCP client should prefer, and it should discard any addresses it receives for the same service through DHCPv4. For the same service means what it says. DNS is the same service whether the transport is IPv4 or IPv6. By which I mean, the payload being sent over the transport is the same in either case - all that differs is the transport. Generally speaking, the application ought not to know - the DHCP client should take care of it. What I think maybe you're really pointing out here is that this requires (a) that we specify which service options refer to the same service between DHCPv4 and DHCPv6 and that (b) dual-stack V4+V6 hosts need to have their DHCPv4 and DHCPv6 clients communicating in some probably unspecifiable way, and (c) applications need to get this information from the DHCP clients using some API that hasn't been defined. What we have done in the past (with DHCPv4) is to not specify these things, and leave them to the implementor. So the DHCPv4 client on a Unix machine typically does things like run route(1) to set up routes and hack /etc/resolv.conf to set up name service, and most of the options are never actually used. We have talked about specifying an API, and I think this is actually a good idea (not everyone agrees, of course!). We shied away from specifying it in RFC3315 because we knew that if we tried, it would never get out the door. Maybe we need to do that sooner rather than later. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 11:58:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27242; Tue, 10 Feb 2004 11:58: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 1AqbCy-00066c-Rk; Tue, 10 Feb 2004 11:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqbC4-00065L-FV for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 11:57: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 LAA27216 for ; Tue, 10 Feb 2004 11:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqbC3-0004fJ-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 11:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqbB9-0004a0-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 11:56:07 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AqbAX-0004Sk-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 11:55:29 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E17CF61BAD; Tue, 10 Feb 2004 17:54:55 +0100 (CET) Date: Tue, 10 Feb 2004 08:10:23 -0800 From: Harald Tveit Alvestrand To: Robert Elz Cc: Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <2015037.1076400623@localhost> In-Reply-To: <2134.1076399906@munnari.OZ.AU> References: <2435506122.1076323711@localhost> <000801c3ef35$831e44d0$6401a8c0@BVolz> <2134.1076399906@munnari.OZ.AU> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On 10. februar 2004 14:58 +0700 Robert Elz wrote: > Date: Mon, 09 Feb 2004 10:48:31 -0800 > From: Harald Tveit Alvestrand > Message-ID: <2435506122.1076323711@localhost> > > | Then stop trying to configure SNTP and NIS. > > Harald, with all respect, this is plain stupid. Yep. I lost my temper, which is nearly always a mistake. Apologies - just because I think you're wrong is no excuse for snapping at you. I still think you're wrong. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 14:02:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02976; Tue, 10 Feb 2004 14:02:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqd91-0000Ag-0A; Tue, 10 Feb 2004 14:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqd85-00007I-7l for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 14:01:05 -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 OAA02940 for ; Tue, 10 Feb 2004 14:01:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqd82-0002hS-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 14:01:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqd77-0002cY-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 14:00:06 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1Aqd6t-0002XZ-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 13:59:51 -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 i1AIxaGn059149; Tue, 10 Feb 2004 13:59:45 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Tim Chown'" , Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Tue, 10 Feb 2004 13:59:45 -0500 Message-ID: <000301c3f008$0fb439e0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040210134549.GC15972@login.ecs.soton.ac.uk> 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 Hum ... I thought we did have some discussion but perhaps I dreamed of = them? Anyway, my thoughts are: - I agree that adding a lifetime to Information-Request information = would be useful: o Conveying a valid lifetime timer to clients for stateless DHCPv6-assigned settings. This could primarily enable planned events, but with a small time-out it could to some extent handle unplanned events at the expense of the additional request traffic. - I also feel that even without a lifetime, a client SHOULD re-request = the parameters when certain events occur. We all assume that a client would = do this whenever it detects a possible network reconnect (such as when the networking cable is plugged back in), but it SHOULD also re-request the parameters whenever addresses obtained via auto-configuration expire (preferred lifetime ends) or when new prefixes are added. Of course, the client should have some throttle control so that it doesn't do this too rapidly (perhaps once every several minutes max.). - When DHCPv6 is used to assign addresses, the lifetime of addresses can = be adjusted (downward) before a renumbering event to assure clients receive timely updated. - Assuring service redundancy. This is outside the scope of DHCP but it = is normally prudent practice to have multiple DNS servers. This means that = a single failure (or need to change a single address) would not cause a significant service interruption. - As reconfigure CAN be used with Information-Request clients (provided those clients have contacted the DHCPv6 server and indicated support for Reconfigure), it could be recommended for clients to support this even = when just using Information-Request. But, I suspect this is likely overkill. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Tim Chown Sent: Tuesday, February 10, 2004 8:46 AM To: dhcwg@ietf.org Subject: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Hi, There have not been any list comments on a draft that I wrote with Stig = and A.K. after Minneapolis on the issue of how nodes using DHCPv6 only for = non address configuration options should leanr ofconfiguration changes. http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-renu= mbe ring-00.txt There has been a comment regarding the Reconfigure message (and lack of use of it?) on the list, though not in the context of this draft. There have also been comments that there are wider issues here, e.g. in terms of node use of DHCP(v6) servers when moving between networks. I would be happy to update the above draft to a -01 version if there are (constructive :) comments. Note that Stig will present this draft and a solution draft in Seoul. Tim _______________________________________________ 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 Feb 10 17:00:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22702; Tue, 10 Feb 2004 17:00:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfvH-0005xb-Hu; Tue, 10 Feb 2004 17:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfuc-0005ns-Qj for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 16:59:22 -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 QAA22593 for ; Tue, 10 Feb 2004 16:59:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfua-0003l7-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 16:59:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqftx-0003cZ-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 16:58:41 -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 1Aqfsu-0003IZ-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 16:57:36 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2004 14:05:12 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1ALv4u5024960; Tue, 10 Feb 2004 13:57:04 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-31.cisco.com [10.86.240.31]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFY83549; Tue, 10 Feb 2004 16:57:02 -0500 (EST) Message-Id: <4.3.2.7.2.20040210164055.01fcc2e0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 16:56:59 -0500 To: Tim Chown From: Ralph Droms Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Cc: dhcwg@ietf.org In-Reply-To: <20040210134549.GC15972@login.ecs.soton.ac.uk> 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.0 required=5.0 tests=AWL 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: , Tim - I think it would be useful to add a section ("Considerations in choosing a solution") that lists some of the issues you hint at in section 5, "Solution space". Here are some candidate considerations: * must support planned renumbering; desirable to support unplanned renumbering * security; e.g., avoid DOS attacks mounted through Reconfigure messages sent from attacker * must update options even if network is not renumbered * desirable to maintain "stateless" property; i.e., no per-client state kept in the server I agree with Bernie's observation that it would be good to add text (already in RFC 3315 for stateful DHCPv6) specifying conditions under which client should send an Information-request, such as reconnection to a link. Another possible solution would be to redefine the semantics of the 'O' flag in RAs, so toggling the 'O' flag would trigger clients to send an Information-request message. Nits: The current citation for stateless DHCPv6 is "Stateless DHCP Service for IPv6", draft-ietf-dhc-dhcpv6-stateless-04.txt, January 2004. (this draft is currently in the RFC Editor pub queue) The current citation for the renumbering procedure draft is "Procedures for Renumbering an IPv6 Network without a Flag Day", draft-ietf-v6ops-renumbering-procedure-00.txt, February 2004. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 17:22:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25076; Tue, 10 Feb 2004 17:22: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 1AqgGX-0000OD-L3; Tue, 10 Feb 2004 17: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 1AqgG5-0000Mv-DX for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 17:21: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 RAA24943 for ; Tue, 10 Feb 2004 17:21:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgG3-0007RD-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:21:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgF1-0007Gs-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:20:27 -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 1AqgEP-000781-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:19:49 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2004 14:27:25 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1AMJHuA022827 for ; Tue, 10 Feb 2004 14:19:18 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-31.cisco.com [10.86.240.31]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFY85601; Tue, 10 Feb 2004 17:18:09 -0500 (EST) Message-Id: <4.3.2.7.2.20040210165848.027fb498@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 17:18:06 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Comments on "DHCP Option for Proxy Server Configuration" 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: , Some comments on "DHCP Option for Proxy Server Configuration", draft-ietf-dhc-proxyserver-opt-00.txt: How do the proxy servers in this option differ from the addresses carried in other options for the same services; e.g.: option 72, WWW server (RFC 2132) option 71, NNTP server (RFC 2132) While the reader can infer that this option is for IPv4 (RFC 2131/RFC 2132), it would be good to mention it specifically in a sentence somewhere. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 17:33:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26246; Tue, 10 Feb 2004 17:33:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgRB-0001D9-SK; Tue, 10 Feb 2004 17: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 1AqgQy-0001Cf-SE for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 17:32: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 RAA26161 for ; Tue, 10 Feb 2004 17:32:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgQw-0001Si-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgQ1-0001Iq-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:31:49 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgPH-00017P-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:31:03 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i1AMUCOr021157 for ; Tue, 10 Feb 2004 22:30:12 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA00881 for ; Tue, 10 Feb 2004 22:30:08 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i1AMU7602826 for dhcwg@ietf.org; Tue, 10 Feb 2004 22:30:07 GMT Date: Tue, 10 Feb 2004 22:30:07 +0000 From: Tim Chown To: dhcwg@ietf.org Message-ID: <20040210223007.GA2626@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-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 Subject: [dhcwg] DHCP-DHCPv6 Issues and IPv4 options drafts Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, These two drafts have now been published. As they may not be copied to the dhc list due to their personal status, their summaries are below. The purpose of the drafts is to form a framework for discussion in Seoul, where Stig Venaas will present the issues draft. Both drafts have a short slot on the agenda. The main options appear to be keeping the functionality separate, or adding IPv4 information options to allow only DHCPv6 to be required for dual-stack nodes. In additional, some "administrative" considerations could/should be made, e.g. whether or not to use a split name space (*.ipv6.foo.com) for early IPv6 deployment. Title : IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Author(s) : T. Chown Filename : draft-chown-dhc-dual-stack-00.txt Pages : 10 Date : 2004-2-10 A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4] for IPv6. This document describes issues identified with dual IP version DHCP interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-dhc-dual-stack-00.txt Title : DHCPv6 IPv4 Information Options Author(s) : C. Cadar Filename : draft-cadar-dhc-dhcpv6-v4options-00.txt Pages : 21 Date : 2004-2-10 To ease the management of a site, the Dynamic Host Configuration Protocol (DHCP) is often used. DHCP exists both for the Internet Protocol Version 4 (DHCPv4 for IPv4) and Version 6 (DHCPv6 for IPv6). To avoid possible pitfalls that occur if both DHCP versions are used and to avoid redundancy, IPv4 Information Options may be transmitted using DHCPv6 as described in this document. In dual-stack IPv4/IPv6 scenarios that employ DHCPv6, DHCPv4 can be completely replaced by using the DHCPv6 IPv4 Information Options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cadar-dhc-dhcpv6-v4options-00.txt Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 17:55:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27641; Tue, 10 Feb 2004 17:55: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 1AqgmV-000312-RY; Tue, 10 Feb 2004 17:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqglk-0002yy-1k for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 17:54: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 RAA27565 for ; Tue, 10 Feb 2004 17:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqglh-000456-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:54:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgkk-0003zE-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:53:14 -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 1Aqgk3-0003nb-01 for dhcwg@ietf.org; Tue, 10 Feb 2004 17:52:32 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2004 15:00:21 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1AMqD4U000233 for ; Tue, 10 Feb 2004 14:52:13 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-31.cisco.com [10.86.240.31]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFY88479; Tue, 10 Feb 2004 17:52:11 -0500 (EST) Message-Id: <4.3.2.7.2.20040210174302.02864790@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 17:52:08 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Comments on "Configured Tunnel End Point Option for DHCPv6" 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: , Some comments on "Configured Tunnel End Point Option for DHCPv6", draft-ietf-dhc-dhcpv6-ctep-opt-00.txt: Because there are several types of tunnels defined in RFC 2893, it would be helpful to mention explicitly the section (section 4, I think?) in which "configured tunnels" are defined. Unless I'm misunderstanding RFC 2893 (which is not unlikely), the endpoint of a configured tunnel should be the IPv4 address of a router that can strip off the IPv4 header and forward the tunnelled IPv6 datagram to its destination. So, the CTEP address for each endpoint should be an IPv4 address? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 19:48:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05929; Tue, 10 Feb 2004 19:48: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 1AqiXp-0000d5-Ot; Tue, 10 Feb 2004 19: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 1AqiXE-0000cD-O4 for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 19:47:24 -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 TAA05746 for ; Tue, 10 Feb 2004 19:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqiXC-0002Mr-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 19:47:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqiWG-0002Co-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 19:46:24 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AqiVM-0001wB-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 19:45:29 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HSW00A8SA2RVM@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 09:44:51 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HSW0037UA24Z3@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 09:44:28 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HSW00LHXA24JR@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 09:44:28 +0900 (KST) Date: Wed, 11 Feb 2004 09:44:20 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Comments on "Configured Tunnel End Point Option for DHCPv6" In-reply-to: <4.3.2.7.2.20040210174302.02864790@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Cc: "'Vijayabhaskar A K'" , "'S. Daniel Park'" Message-id: <01d801c3f038$32cd3550$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 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 > Because there are several types of tunnels defined in RFC > 2893, it would be helpful to mention explicitly the section (section 4, I > think?) in which "configured tunnels" are defined. Ok. I will try do that. > Unless I'm misunderstanding RFC 2893 (which is not unlikely), > the endpoint of a configured tunnel should be the IPv4 address of a router > that can strip off the IPv4 header and forward the tunnelled IPv6 datagram to its > destination. So, the CTEP address for each endpoint should > be an IPv4 address? Above scenario is different from this draft. For the IPv6 connectivity via tunnel, we can consider two kinds of scenarios as below; 1) [IPv6 host]----[IPv6/4]---[IPv4 legacy network]---[IPv4/6]---[IPv6 host] =============================== configured tunnel 2) [IPv4/6 host]---[IPv4/6]---[IPv6] ======= configured tunnel This draft aims the first scenario, so IPv6 tunnel end-point address should be delegated to IPv6 host from DHCPv6 server. For the second scenario, IPv4 address should be used for configured tunnel end-point on the IPv4/6 dual host as you indicated. For that, I also proposed a new draft. http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-00.txt Hope this helps... Daniel _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 19:49:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06078; Tue, 10 Feb 2004 19:49: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 1AqiYm-0000kD-Gk; Tue, 10 Feb 2004 19:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiY8-0000ff-Ma for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 19:48:20 -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 TAA05867 for ; Tue, 10 Feb 2004 19:48:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqiY6-0002X1-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 19:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqiXE-0002ND-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 19:47:25 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AqiWO-00026e-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 19:46:33 -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 <0HSW00C0JA4PT6@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 09:46:01 +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 <0HSW0094QA4IYQ@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 09:45:54 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HSW00MAEA4HB3@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 09:45:54 +0900 (KST) Date: Wed, 11 Feb 2004 09:45:46 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Comments on "Configured Tunnel End Point Option for DHCPv6" In-reply-to: <4.3.2.7.2.20040210174302.02864790@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <01e301c3f038$660fc450$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_aHMY1ZuoCmRuo1Rv3qPaEA)" 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.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,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. --Boundary_(ID_aHMY1ZuoCmRuo1Rv3qPaEA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > Because there are several types of tunnels defined in RFC 2893, it > would be helpful to mention explicitly the section (section 4, I > think?) in which "configured tunnels" are defined. Ok. I will try do that. > Unless I'm misunderstanding RFC 2893 (which is not unlikely), the > endpoint of a configured tunnel should be the IPv4 address of a router > that can strip off the IPv4 header and forward the tunnelled IPv6 datagram to its > destination. So, the CTEP address for each endpoint should be an IPv4 > address? Above scenario is different from this draft. For the IPv6 connectivity via tunnel, we can consider two kinds of scenarios as below; 1) [IPv6 host]----[IPv6/4]---[IPv4 legacy network]---[IPv4/6]---[IPv6 host] ======================= configured tunnel 2) [IPv4/6 host]---[IPv4/6]---[IPv6] ======= configured tunnel This draft aims the first scenario, so IPv6 tunnel end-point address should be delegated to IPv6 host from DHCPv6 server. For the second scenario, IPv4 address should be used for configured tunnel end-point on the IPv4/6 dual host as you indicated. For that, I also proposed a new draft. http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-00.txt Hope this helps... Daniel --Boundary_(ID_aHMY1ZuoCmRuo1Rv3qPaEA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 메시지

> Because there are several types of tunnels defined in RFC 2893, it
> would be helpful to mention explicitly the section (section
4, I
> think?) in which "configured tunnels" are defined.

Ok. I will try do that.

> Unless I'm misunderstanding RFC 2893 (which is not unlikely), the
> endpoint of a configured tunnel should be the IPv4 address of a
router
> that can strip off the IPv4 header and forward the tunnelled IPv6
datagram to its
> destination.  So, the CTEP address for each endpoint should be an IPv4
> address?

Above scenario is different from this draft. For the IPv6 connectivity via tunnel, we can consider two kinds of scenarios as below;

1) [IPv6 host]----[IPv6/4]---[IPv4 legacy network]---[IPv4/6]---[IPv6 host]
                                         =======================
                                                 configured tunnel

2) [IPv4/6 host]---[IPv4/6]---[IPv6]
                     =======
              configured tunnel


This draft aims the first scenario, so IPv6 tunnel end-point address should be delegated to IPv6 host from DHCPv6 server.


For the second scenario, IPv4 address should be used for configured tunnel end-point on the IPv4/6 dual host as you indicated. For that, I also proposed a new draft. http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-00.txt

Hope this helps...




Daniel

--Boundary_(ID_aHMY1ZuoCmRuo1Rv3qPaEA)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 21:09:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12566; Tue, 10 Feb 2004 21:09: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 1AqjoD-0007wE-Th; Tue, 10 Feb 2004 21:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqjna-0007rh-G0 for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 21:08:22 -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 VAA12520 for ; Tue, 10 Feb 2004 21:08:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqjnX-0006fd-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:08:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqjmi-0006Ze-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:07:29 -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 1Aqjlt-0006LN-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:06:37 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1B265uA010371; Tue, 10 Feb 2004 18:06:05 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-31.cisco.com [10.86.240.31]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFY99043; Tue, 10 Feb 2004 21:06:03 -0500 (EST) Message-Id: <4.3.2.7.2.20040210210233.00ca6100@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 21:06:03 -0500 To: "S. Daniel Park" From: Ralph Droms Subject: RE: [dhcwg] Comments on "Configured Tunnel End Point Option for DHCPv6" Cc: dhcwg@ietf.org, "'Vijayabhaskar A K'" , "'S. Daniel Park'" In-Reply-To: <01d801c3f038$32cd3550$67cadba8@LocalHost> References: <4.3.2.7.2.20040210174302.02864790@flask.cisco.com> 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.0 required=5.0 tests=AWL 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: , Daniel - I'm still having trouble understanding the scenario this draft is addressing. In scenario 1, where are the endpoints of the configured tunnel? The two IPv6 hosts? If that's right, is one of the IPv6 hosts is the DHCPv6 client, which receives the CTEP option containing the address of the other IPv6 host? - Ralph At 09:44 AM 2/11/2004 +0900, S. Daniel Park wrote: > > Unless I'm misunderstanding RFC 2893 (which is not unlikely), > > the endpoint of a configured tunnel should be the IPv4 address > > of a router > > that can strip off the IPv4 header and forward the tunnelled > > IPv6 datagram to its > > destination. So, the CTEP address for each endpoint should > > be an IPv4 address? > >Above scenario is different from this draft. For the IPv6 connectivity >via tunnel, >we can consider two kinds of scenarios as below; > >1) [IPv6 host]----[IPv6/4]---[IPv4 legacy network]---[IPv4/6]---[IPv6 >host] > =============================== > configured tunnel > >2) [IPv4/6 host]---[IPv4/6]---[IPv6] > ======= > configured tunnel > > >This draft aims the first scenario, so IPv6 tunnel end-point address >should be >delegated to IPv6 host from DHCPv6 server. > > >For the second scenario, IPv4 address should be used for configured >tunnel end-point >on the IPv4/6 dual host as you indicated. For that, I also proposed a >new draft. >http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-00.txt > >Hope this helps... > > > > >Daniel _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 21:11:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12702; Tue, 10 Feb 2004 21:11: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 1AqjqA-0008Db-EU; Tue, 10 Feb 2004 21: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 1AqQhP-00050Y-F1 for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 00:44:43 -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 AAA17727 for ; Tue, 10 Feb 2004 00:44:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqQhM-00019m-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 00:44:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqQgT-00014r-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 00:43:46 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AqQg8-0000z5-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 00:43:24 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A95B715210; Tue, 10 Feb 2004 14:43:24 +0900 (JST) Date: Tue, 10 Feb 2004 14:43:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Harald Tveit Alvestrand Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt In-Reply-To: <2427813621.1076316018@localhost> References: <2427813621.1076316018@localhost> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 09 Feb 2004 08:40:18 -0800, >>>>> Harald Tveit Alvestrand said: > - In all the instances I've seen so far, declare that if you need an IPv4 > address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) - no > other changes needed. A couple of minor notes: - ::12.34.56.78 is NOT an IPv4-mapped IPv6 address (but an IPv4-compatible IPv6 address). You should probably have meant ::ffff:12.34.56.78. - if we really go with this approach, we should also consider draft-itojun-v6ops-v4mapped-harmful-02.txt which proposes "nodes SHOULD NOT generate packets that contain IPv4-mapped addresses in any field" in a packet sent on the wire in order to avoid confusion with API usages of IPv4-mapped addresses. Though this is still an individual draft, there seems to be a consensus on "no IPv4-mapped IPv6 addresses in the wire", at least to some extent. (just to avoid unnecessary flame: I'm not talking about the API usage of IPv4-mapped IPv6 addresses (whether it's a good idea, etc) at all. In particular, please do not confuse this issue with draft-cmetz-v6ops-v4mapped-api-harmful-01.txt) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 21:44:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13758; Tue, 10 Feb 2004 21:44: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 1AqkM5-0002CS-Ec; Tue, 10 Feb 2004 21: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 1AqkLM-0002BR-UR for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 21:43: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 VAA13679 for ; Tue, 10 Feb 2004 21:43:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkLK-0002cY-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:43:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqkKQ-0002VJ-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:42:19 -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 1AqkJW-0002J2-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:41:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2004 18:48:20 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1B2eo4U000322 for ; Tue, 10 Feb 2004 18:40:51 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-31.cisco.com [10.86.240.31]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFZ00651; Tue, 10 Feb 2004 21:40:49 -0500 (EST) Message-Id: <4.3.2.7.2.20040210213212.02962220@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 21:40:46 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Questions about "The Extended Remote Boot Option for DHCPv4" 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 have a couple of questions about "The Extended Remote Boot Option for DHCPv4", draft-ietf-dhc-opt-extrboot-00.txt. Is the purpose of this option to send a list of candidate TFTP servers, which the DHCP client contacts to download one or more specified files? Does the list contain a list of entries, each of which looks like: Server name or IPv4 address File 1 File 2 File 3 The semantics, then are to contact the first server in the list. If the DHCP client can access a TFTP service on that first server, the client sequentially downloads each of the files associated with that server and quits processing the option. If the client cannot contact the first server, it tries the second server. If the DHCP client can access a TFTP service, it downloads each of the files associated with the second server. Is my interpretation correct? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 21:52:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14050; Tue, 10 Feb 2004 21:52: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 1AqkTo-0002sG-Ew; Tue, 10 Feb 2004 21:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkTE-0002ry-Lm for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 21:51:24 -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 VAA14039 for ; Tue, 10 Feb 2004 21:51:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkTB-0003UT-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:51:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqkSH-0003P5-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:50:26 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AqkRl-0003IR-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 21:49:53 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HSW00G0JFTPPE@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 11:49:01 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HSW00MQFFT21L@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 11:48:39 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HSW007BFFT11Y@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 11 Feb 2004 11:48:38 +0900 (KST) Date: Wed, 11 Feb 2004 11:48:29 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Comments on "Configured Tunnel End Point Option for DHCPv6" In-reply-to: <4.3.2.7.2.20040210210233.00ca6100@flask.cisco.com> To: "'Ralph Droms'" Cc: dhcwg@ietf.org, "'Vijayabhaskar A K'" Message-id: <024b01c3f049$8b0f2410$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 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 [IPv6 host]----[IPv6/4 Router]===IPv4===[IPv4/6 Router] | (1) configured Tunnel | +--------[IPv6 Router]----IPv6 (2) For usage of Configured Tunnel via IPv4, IPv6 host must make use of (1) as destinaiton and its IPv6 address will be a tunnel end-point address. Hope this helps Daniel > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, February 11, 2004 11:06 AM > To: S. Daniel Park > Cc: dhcwg@ietf.org; 'Vijayabhaskar A K'; 'S. Daniel Park' > Subject: RE: [dhcwg] Comments on "Configured Tunnel End Point > Option for DHCPv6" > > > Daniel - I'm still having trouble understanding the scenario > this draft is addressing. In scenario 1, where are the > endpoints of the configured tunnel? The two IPv6 hosts? If > that's right, is one of the IPv6 hosts is the DHCPv6 client, > which receives the CTEP option containing the address of the > other IPv6 host? > > - Ralph > > At 09:44 AM 2/11/2004 +0900, S. Daniel Park wrote: > > > > Unless I'm misunderstanding RFC 2893 (which is not unlikely), the > > > endpoint of a configured tunnel should be the IPv4 address of a > > > router that can strip off the IPv4 header and forward the > tunnelled > > > IPv6 datagram to its > > > destination. So, the CTEP address for each endpoint should > > > be an IPv4 address? > > > >Above scenario is different from this draft. For the IPv6 > connectivity > >via tunnel, we can consider two kinds of scenarios as below; > > > >1) [IPv6 host]----[IPv6/4]---[IPv4 legacy > network]---[IPv4/6]---[IPv6 > >host] > > =============================== > > configured tunnel > > > >2) [IPv4/6 host]---[IPv4/6]---[IPv6] > > ======= > > configured tunnel > > > > > >This draft aims the first scenario, so IPv6 tunnel end-point address > >should be delegated to IPv6 host from DHCPv6 server. > > > > > >For the second scenario, IPv4 address should be used for configured > >tunnel end-point on the IPv4/6 dual host as you indicated. > For that, I > >also proposed a new draft. > >http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4- opt-00.txt > >Hope this helps... > > > > >Daniel _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 10 23:14:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16324; Tue, 10 Feb 2004 23:14: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 1AqllB-0007th-ES; Tue, 10 Feb 2004 23: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 1Aqlkm-0007lS-SY for dhcwg@optimus.ietf.org; Tue, 10 Feb 2004 23:13: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 XAA16283 for ; Tue, 10 Feb 2004 23:13:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqlkk-0003zV-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 23:13:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqlje-0003tf-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 23:12:27 -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 1Aqlin-0003i0-00 for dhcwg@ietf.org; Tue, 10 Feb 2004 23:11:33 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2004 20:18:32 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1B4B14U028757 for ; Tue, 10 Feb 2004 20:11:01 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-31.cisco.com [10.86.240.31]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFZ03182; Tue, 10 Feb 2004 23:11:00 -0500 (EST) Message-Id: <4.3.2.7.2.20040210230453.02971ef0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 23:10:57 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Questions about "DHCPv6 Support for Remote Boot" 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: , Am I understanding draft-ietf-dhc-dhcpv6-opt-rboot-00.txt correctly - it provides much the same information in a DHCPv6 option that draft-ietf-dhc-opt-extrboot provides in a DHCPv4 option? That is, a list of TFTP servers, with a list of files associated with each server? Seems like there should be a way to specify the DNS name of the TFTP server as well as the IPv6 address. Unless there may be more sub-option types in the future, the OPTION_REMOTE_BOOT_PARAMS option could be omitted. Is there any chance that it might be required to use some other transport mechanism such as FTP or HTTP? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 01:18:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21552; Wed, 11 Feb 2004 01: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 1AqnhB-00007i-Co; Wed, 11 Feb 2004 01: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 1Aqngc-0008Sm-LT for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 01:17:26 -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 BAA21538 for ; Wed, 11 Feb 2004 01:17:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqngZ-0002CX-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 01:17:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqnfd-000281-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 01:16:26 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AqnfP-000239-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 01:16:12 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i1B6Fe8m018353; Wed, 11 Feb 2004 07:15:40 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i1B6FfQo029637; Wed, 11 Feb 2004 07:15:41 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 11 Feb 2004 07:15:41 +0100 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <20040211061541.GB29599@sverresborg.uninett.no> References: <2427813621.1076316018@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, Feb 10, 2004 at 02:43:27PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: [...] > - if we really go with this approach, we should also consider > draft-itojun-v6ops-v4mapped-harmful-02.txt > which proposes "nodes SHOULD NOT generate packets that contain > IPv4-mapped addresses in any field" in a packet sent on the wire in > order to avoid confusion with API usages of IPv4-mapped addresses. > Though this is still an individual draft, there seems to be a > consensus on "no IPv4-mapped IPv6 addresses in the wire", at least > to some extent. I agree with the concerns for IP header fields which I believe the draft discusses. I don't see immediate problems with this usage in the IP payload. I don't think the draft says it's wrong to use them in payload either. It says something about no IPv4-mapped addresses on the wire, but when discussing issues and other places, it only talks about IP header fields, which I think is the problem it discusses, and rightly so. So I think the concensus is "no IPv4-mapped IPv6 addresses" in IPv6 header fields. Perhaps my understanding is different from the rest. But I suggest people read the draft before refusing this approach. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 04:33:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24415; Wed, 11 Feb 2004 04: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 1Aqqjw-0004Hm-BJ; Wed, 11 Feb 2004 04:33:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqjY-0004E3-By for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 04:32: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 EAA24356 for ; Wed, 11 Feb 2004 04:32:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqqjV-00052d-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 04:32:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqqif-0004wa-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 04:31:46 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1AqqiC-0004pS-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 04:31:16 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id 06F4E1C00F8E; Wed, 11 Feb 2004 04:31:14 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1B94gZ04463; Wed, 11 Feb 2004 14:34:42 +0530 (IST) Message-ID: <4029F658.9060101@india.hp.com> Date: Wed, 11 Feb 2004 15:01:04 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Questions about "The Extended Remote Boot Option for DHCPv4" References: <4.3.2.7.2.20040210213212.02962220@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040210213212.02962220@flask.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; 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 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 Yes, your interpretations are correct.. ~ Vijay Ralph Droms wrote: > I have a couple of questions about "The Extended Remote Boot Option for > DHCPv4", draft-ietf-dhc-opt-extrboot-00.txt. > > Is the purpose of this option to send a list of candidate TFTP servers, > which the DHCP client contacts to download one or more specified files? > Does the list contain a list of entries, each of which looks like: > > Server name or IPv4 address > File 1 > File 2 > File 3 > > The semantics, then are to contact the first server in the list. If the > DHCP client can access a TFTP service on that first server, the client > sequentially downloads each of the files associated with that server and > quits processing the option. If the client cannot contact the first > server, > it tries the second server. If the DHCP client can access a TFTP > service, > it downloads each of the files associated with the second server. Is my > interpretation correct? > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 04:56:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25152; Wed, 11 Feb 2004 04:56: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 1Aqr69-0005mv-3g; Wed, 11 Feb 2004 04:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqr5g-0005m9-FE for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 04:55: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 EAA25144 for ; Wed, 11 Feb 2004 04:55:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqr5d-0007RA-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 04:55:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqr4g-0007Me-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 04:54:31 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1Aqr45-0007I1-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 04:53:53 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id C21431C0254E; Wed, 11 Feb 2004 04:53:51 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1B9RJZ10108; Wed, 11 Feb 2004 14:57:19 +0530 (IST) Message-ID: <4029FBA6.1050806@india.hp.com> Date: Wed, 11 Feb 2004 15:23:42 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Questions about "DHCPv6 Support for Remote Boot" References: <4.3.2.7.2.20040210230453.02971ef0@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040210230453.02971ef0@flask.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph Droms wrote: > Am I understanding draft-ietf-dhc-dhcpv6-opt-rboot-00.txt correctly - it > provides much the same information in a DHCPv6 option that > draft-ietf-dhc-opt-extrboot provides in a DHCPv4 option? That is, a > list of > TFTP servers, with a list of files associated with each server? Yes. You are correct... > > Seems like there should be a way to specify the DNS name of the TFTP > server > as well as the IPv6 address. I thought about that.. But, as all the other options are specified as addresses rather than names, to maintain the consistency I used address format.. Moreover, I couldn't imagine the advantage of names over IP addresses in this case. > > Unless there may be more sub-option types in the future, the > OPTION_REMOTE_BOOT_PARAMS option could be omitted. Basically, OPTION_REMOTE_BOOT_PARAMS is for coupling the tftp server and the file names.. > > Is there any chance that it might be required to use some other transport > mechanism such as FTP or HTTP? I couldn't think of any.. TFTP is the widely used mechanism for downloading boot images (or) installing the depots.. ~ Vijay > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 05:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25643; Wed, 11 Feb 2004 05:24: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 1AqrXF-0007E2-RV; Wed, 11 Feb 2004 05: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 1AqrWo-0007DZ-Nf for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 05:23:34 -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 FAA25637 for ; Wed, 11 Feb 2004 05:23:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqrWl-0001zB-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 05:23:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqrVo-0001uG-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 05:22:33 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1AqrUv-0001pQ-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 05:21:37 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id 9662F1C0170A; Wed, 11 Feb 2004 05:21:34 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1B9t0Z16705; Wed, 11 Feb 2004 15:25:00 +0530 (IST) Message-ID: <402A0224.80507@india.hp.com> Date: Wed, 11 Feb 2004 15:51:24 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas Cc: "JINMEI Tatuya / ?$B?@L@C#:H" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt References: <2427813621.1076316018@localhost> <20040211061541.GB29599@sverresborg.uninett.no> In-Reply-To: <20040211061541.GB29599@sverresborg.uninett.no> 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 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 draft-itojun-v6ops-v4mapped-harmful seems to be expired. Do we need to consider this still? ~ Vijay Stig Venaas wrote: >On Tue, Feb 10, 2004 at 02:43:27PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: >[...] > > >>- if we really go with this approach, we should also consider >> draft-itojun-v6ops-v4mapped-harmful-02.txt >> which proposes "nodes SHOULD NOT generate packets that contain >> IPv4-mapped addresses in any field" in a packet sent on the wire in >> order to avoid confusion with API usages of IPv4-mapped addresses. >> Though this is still an individual draft, there seems to be a >> consensus on "no IPv4-mapped IPv6 addresses in the wire", at least >> to some extent. >> >> > >I agree with the concerns for IP header fields which I believe the >draft discusses. I don't see immediate problems with this usage in >the IP payload. I don't think the draft says it's wrong to use them >in payload either. It says something about no IPv4-mapped addresses >on the wire, but when discussing issues and other places, it only >talks about IP header fields, which I think is the problem it >discusses, and rightly so. > >So I think the concensus is "no IPv4-mapped IPv6 addresses" in IPv6 >header fields. Perhaps my understanding is different from the rest. >But I suggest people read the draft before refusing this approach. > >Stig > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 05:41:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26247; Wed, 11 Feb 2004 05:41: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 1Aqrni-0008Ud-0H; Wed, 11 Feb 2004 05:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqrnF-0008UD-ON for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 05:40: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 FAA26209 for ; Wed, 11 Feb 2004 05:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqrnC-0003pD-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 05:40:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqrmD-0003jE-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 05:39:29 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AqrlE-0003Yw-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 05:38:28 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i1BAbt8m022964; Wed, 11 Feb 2004 11:37:55 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i1BAbuQT029944; Wed, 11 Feb 2004 11:37:56 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 11 Feb 2004 11:37:56 +0100 From: Stig Venaas To: Vijayabhaskar A K Cc: "JINMEI Tatuya / ?$B?@L@C#:H" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt Message-ID: <20040211103756.GI29785@sverresborg.uninett.no> References: <2427813621.1076316018@localhost> <20040211061541.GB29599@sverresborg.uninett.no> <402A0224.80507@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402A0224.80507@india.hp.com> User-Agent: Mutt/1.4.1i 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Feb 11, 2004 at 03:51:24PM +0530, Vijayabhaskar A K wrote: > draft-itojun-v6ops-v4mapped-harmful seems to be expired. Do we need to > consider this still? It might be expired, but it's still a really issue. But IMO the issue is mapped addresses in IP headers, not in the payload. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 06:17:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27092; Wed, 11 Feb 2004 06:17: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 1AqsMW-0001j3-S3; Wed, 11 Feb 2004 06:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqsM8-0001id-S3 for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 06:16: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 GAA27083 for ; Wed, 11 Feb 2004 06:16:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqsM5-0006vw-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 06:16:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqsLG-0006qr-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 06:15:43 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1AqsKG-0006lz-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 06:14:40 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1BBEW803234; Wed, 11 Feb 2004 18:14:33 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1BBBBC00485; Wed, 11 Feb 2004 18:11:26 +0700 (ICT) From: Robert Elz To: Harald Tveit Alvestrand cc: Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt In-Reply-To: <2015037.1076400623@localhost> References: <2015037.1076400623@localhost> <2435506122.1076323711@localhost> <000801c3ef35$831e44d0$6401a8c0@BVolz> <2134.1076399906@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Feb 2004 18:11:11 +0700 Message-ID: <17287.1076497871@munnari.OZ.AU> 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Tue, 10 Feb 2004 08:10:23 -0800 From: Harald Tveit Alvestrand Message-ID: <2015037.1076400623@localhost> | Apologies - just because I think you're wrong is no excuse for snapping at | you. No apologies needed, at least not for me - the message I replied to wasn't directed (specifically) at me. In any case, I didn't view your comment as in any way objectionable, just farcical... | I still think you're wrong. I fully understand your point of view. And I certainly agree, getting different config info from different sources is a problem, and one that it would be nice to have a clean solution to. But I don't think you can really expect DHCP to suddenly provide it, or not in the context of the DHCPv6 NIS configuration option in any case. The problem is much broader than that - there are many more sources of config info than just N interfaces each providing host config information via DHCP. Config info is also available via well known addresses (ie: SNTP could be using the well known multicast address, instead of a particular server) or via SLP, or perhaps even DNS SRV records, or ... Any and all of that might conflict with any other of it. What a host should do in circumstances like those isn't easy to specify. DHCP on the other hand has been as it is now since day 1 - it gets config info about an interface, and throws in all kinds of host configuration at the same time - naturally leading to (potentially) multiple different configs being received. DHCPv4 is like that, DHCPv6 isn't any different. Altering that would be a major project, and NIS configuration just isn't important enough to embark upon that! kre ps: I haven't read today's list traffic yet (the last message I saw was my own - the one full of typos). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 09:00:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01085; Wed, 11 Feb 2004 09:00: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 1AquuI-0003iw-V9; Wed, 11 Feb 2004 09:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqutx-0003g6-0W for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 08:59: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 IAA01012 for ; Wed, 11 Feb 2004 08:59:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqutv-0006QJ-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 08:59:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqusy-0006J9-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 08:58:40 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1AqusC-0006Cg-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 08:57:52 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel7.hp.com (Postfix) with ESMTP id 937F51C0179A; Wed, 11 Feb 2004 08:57:46 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1BDV2Z06491; Wed, 11 Feb 2004 19:01:02 +0530 (IST) Message-ID: <402A34D0.1060800@india.hp.com> Date: Wed, 11 Feb 2004 19:27:36 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas Cc: "JINMEI Tatuya / ?$B?@L@C#:H" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt References: <2427813621.1076316018@localhost> <20040211061541.GB29599@sverresborg.uninett.no> <402A0224.80507@india.hp.com> <20040211103756.GI29785@sverresborg.uninett.no> In-Reply-To: <20040211103756.GI29785@sverresborg.uninett.no> 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 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 draft-itojun-v6ops-v4mapped-harmful says: o IPv6 nodes SHOULD NOT generate packets that contain IPv4-mapped addresses in any field. (As a particular exception, it MAY be acceptable for fields referring to third-party nodes to contain IPv4-mapped addresses. Implementors must ensure that, where this is allowed, it is done with great care.) I guess, our situation perfectly falls in this.. There is no harm in sending the v4 mapped service addresses.. For example, We store IPv6 addresses, IPv4 addresses and IPv4 mapped IPv6 addresses of DNS in /etc/resolv.conf.. The underlying stack can take care of this and make sure that IPv4 packet is sent if the destination is IPV4 mapped IPv6 address.. ~ Vijay Stig Venaas wrote: >On Wed, Feb 11, 2004 at 03:51:24PM +0530, Vijayabhaskar A K wrote: > > >>draft-itojun-v6ops-v4mapped-harmful seems to be expired. Do we need to >>consider this still? >> >> > >It might be expired, but it's still a really issue. But IMO the issue >is mapped addresses in IP headers, not in the payload. > >Stig > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 09:13:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01576; Wed, 11 Feb 2004 09:13: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 1Aqv6r-0005AD-5E; Wed, 11 Feb 2004 09:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv6Z-00058D-Qe for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 09:12:43 -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 JAA01566 for ; Wed, 11 Feb 2004 09:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv6Y-0007m4-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 09:12:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqv5h-0007gb-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 09:11:50 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv5B-0007an-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 09:11:17 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel9.hp.com (Postfix) with ESMTP id 9D2FA1C049A7; Wed, 11 Feb 2004 09:11:14 -0500 (EST) Received: from india.hp.com (nt23073.india.hp.com [15.42.230.73]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1BDiVZ09572; Wed, 11 Feb 2004 19:14:32 +0530 (IST) Message-ID: <402A3800.3090705@india.hp.com> Date: Wed, 11 Feb 2004 19:41:12 +0530 From: Senthil Kumar B Organization: Hewlett Packard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on "DHCP Option for Proxy Server Configuration" References: <4.3.2.7.2.20040210165848.027fb498@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040210165848.027fb498@flask.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph Droms wrote: > Some comments on "DHCP Option for Proxy Server Configuration", > draft-ietf-dhc-proxyserver-opt-00.txt: > > How do the proxy servers in this option differ from the addresses > carried in > other options for the same services; e.g.: > > option 72, WWW server (RFC 2132) > option 71, NNTP server (RFC 2132) I believe the options (72 & 71) defined in RFC 2132 refer to the WWW / NNTP server itself. The options defined in this draft refer to the proxies for the same through which respective servers (HTTP / NNTP / FTP) could be reached. > While the reader can infer that this option is for IPv4 (RFC 2131/RFC > 2132), > it would be good to mention it specifically in a sentence somewhere. You are correct. I should have mentioned that these options are for IPv4. Will update this comment. > - 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 Wed Feb 11 13:58:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13894; Wed, 11 Feb 2004 13:58: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 1AqzYe-0000wE-Ij; Wed, 11 Feb 2004 13:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzYY-0000vw-A3 for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 13:57: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 NAA13853 for ; Wed, 11 Feb 2004 13:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzYV-0006PJ-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 13:57:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzXf-0006JS-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 13:56:59 -0500 Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx with smtp (Exim 4.12) id 1AqzWx-0006Dz-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 13:56:15 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp102.mail.sc5.yahoo.com with SMTP; 11 Feb 2004 18:56:14 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Wed, 11 Feb 2004 11:00:51 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <06362392-58F6-11D8-A6E8-000A95D9C74C@fugue.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.2 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 Wow! This sure has been a contentious thread.... I must respectfully disagree with the IETF's position regarding IPR and state my support for [what I believe to be] Ted's position. I'm certain that the current IETF policy was constructed after serious and significant negotiations among the interested parties and truly represents a compromise that all felt they could live with. I'm also relatively certain that some work which is codified in RFCs was initially performed for commercial rather than altruistic reasons. The "reasonable and non-discriminatory" terms of most IPR claims was probably the best language that a compromise could contain. However, if I were attempting to either market a commercial product or distribute an open-source one, I'd be extremely wary of including support for ANY technology in a product if there were IPR claims for it that included the "reasonable and non-discriminatory" terms, precisely because I do not have the deep-pocket resources to defend against claims of patent infringement or other IPR claims. That would mean specifically that I would choose NOT to implement some part of an RFC, even if that omission might significantly reduce the usefulness of my product. I suspect that there are more developers besides Ted and myself that have similar concerns. This is, agreed, not an issue that the DHC Working Group can solve. It must be solved by the IETF for the community as a whole and can easily lead the unwary down several rat-holes, not the least of which is, "can a vendor claim RFC-compliance for a product if they have not implemented some portion of the RFC because they could not reach agreement with an IPR-holder over license terms?" We DON'T want this to happen. Precisely because I don't want IETF to become splintered over IPR claims, I not only support Ted's contention that the typical license terms are too vague, I believe that we should NOT advance this draft, and also stop advancement of any other draft containing technology subject to IPR claims. Further, I would support withdrawing ANY portion of an RFC that is based on technology that could conceivably subject to claims by an IPR holder. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 15:36:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20698; Wed, 11 Feb 2004 15:36:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar15W-0002Ym-5o; Wed, 11 Feb 2004 15: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 1Ar14f-0002Wd-4l for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 15:35:09 -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 PAA20593 for ; Wed, 11 Feb 2004 15:35:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar14d-0001ce-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 15:35:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar13c-0001UX-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 15:34:05 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Ar138-0001L0-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 15:33:34 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 11 Feb 2004 12:33:24 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1BKX0T4015494; Wed, 11 Feb 2004 15:33:01 -0500 (EST) Received: from mjs-xp.cisco.com ([161.44.65.244]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFZ60072; Wed, 11 Feb 2004 15:32:59 -0500 (EST) Message-Id: <4.3.2.7.2.20040211141458.02466c20@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Feb 2004 15:32:11 -0500 To: Ralph Droms From: Mark Stapp Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Cc: In-Reply-To: References: <06362392-58F6-11D8-A6E8-000A95D9C74C@fugue.com> 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.0 required=5.0 tests=none 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: , where can we go from here? the people who want to stop this draft are basically saying, "we will stop any drafts from people who've agreed to RAND license their IP, and we will stop any drafts as soon as people other than the authors agree to RAND license their IP." it doesn't seem reasonable to me to expect that each vendor should have to meet different IPR expectations in response to the different temperatures of all of the individual working groups. the ietf's consistent overall expectation allows the standards process to continue in a world where intellectual property exists, and allows competing commercial vendors to contribute. some people in the wg appear to believe that stopping this draft will allow them to make a statement to the ietf which will lead it to change its expectations in a way that suits them. as someone whose work has become the victim of this energy, I can only ask again that the people who object to the ietf's overall expectation address it in the IPR wg. can Ralph or the ADs offer any guidance about whether this kind of storm has blown up in other groups, and about how we should proceed? -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 11 16:28:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27189; Wed, 11 Feb 2004 16:28: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 1Ar1to-0008Vd-Mf; Wed, 11 Feb 2004 16:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1ta-0008Uo-HU for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 16:27:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27077; Wed, 11 Feb 2004 16:27:43 -0500 (EST) Message-Id: <200402112127.QAA27077@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, 11 Feb 2004 16:27:43 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-10.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-10.txt Pages : 37 Date : 2004-2-10 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-10.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-10.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-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10165452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-server-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10165452.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 Feb 11 18:31:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10203; Wed, 11 Feb 2004 18:31: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 1Ar3os-0001nw-AX; Wed, 11 Feb 2004 18: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 1Ar3oE-0001k4-Nh for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 18:30: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 SAA10026 for ; Wed, 11 Feb 2004 18:30:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3oB-0004wv-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 18:30:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3mq-0004en-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 18:28:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar3lT-0004N1-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 18:27:31 -0500 Received: from pan.gwi.net ([207.5.128.165]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar3hk-0008NA-Dw for dhcwg@ietf.org; Wed, 11 Feb 2004 18:23:40 -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 i1BNNDGn075512; Wed, 11 Feb 2004 18:23:18 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: Cc: "'Tim Chown'" , Subject: RE: [dhcwg] DHCP-DHCPv6 Issues and IPv4 options drafts Date: Wed, 11 Feb 2004 18:23:24 -0500 Message-ID: <000001c3f0f6$0c5e6600$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: <20040210223007.GA2626@login.ecs.soton.ac.uk> 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 Hi: I've read draft-chown-dhc-dual-stack-00.txt and skimmed draft-cadar-dhc-dhcpv6-v4options-00.txt and have the following comments. First, I personally severely dislike the idea of using DHCPv6 to also configure IPv4. For one, this really doesn't solve anything as there are still IPv4 only hosts you have to configure, and they can not use DHCPv6. So, in ANY reasonable world where you have IPv4-only hosts and dual-stack hosts you MUST run both DHCPv4 and DHCPv6. You have no choice. You must consider: 1. What advantage is there for configuring IPv4 information into DHCPv6 servers when the DHCPv4 servers need to be configured anyway to support IPv4-only hosts. You're still duplicating information. 2. What happens if there are DHCPv6 servers that don't return IPv4 information? Does this mean the client can't run IPv4 (since it won't do DHCPv4). 3. What happens if the IPv6 interface (transport) is started AFTER = DHCPv4 was used to configure the client? Does the client simply discard the = current IPv4 information? What happens if the IPv6 interface (transport) is = switched off? Should the client start DHCPv4 then? 4. Unless the DHCPv4 and DHCPv6 servers are able to communicate in some = way (perhaps they are running in the same image or the DHCPv6 uses DHCPv4 to = get leases for clients that need IPv4 addresses), this may result in further fragmenting the available IPv4 address space (since now some needs to be allocated to the DHCPv6 server to dole out to dual hosts clients). In = many networks, this is probably no big deal; but if addresses are constrained = ... I guess we'd all be happy since we'd just say switch to IPv6-only? The bottom line is that DHCPv4 must continue to exist as long as you = have IPv4-only or dual stack hosts. Some specific issues with the draft-cadar-dhc-dhcpv6-v4options-00.txt (remember that I'm NOT for this approach): - Why go through the work of defining DHCPv6 options for every DHCPv4 = option that someone may want? If we go down this road of using DHCPv6 to = configure IPv4, we should just have a single DHCPv6 option that can be used to encapsulate DHCPv4 options. Note that this encapsulation option may be = used many times within a single message if needed (depending on scope). Note: I do believe we should document what DHCPv4 options MUST NOT be allowed to be encapsulated; for example addresses may be communicated = with IAADDR_IPv4 options. - The IAADDR_IPV4 option is adding new semantics for IPv4 addresses (the lifetimes). This is not a concept IPv4 has had and I'm not sure why we = would want to introduce this concept (though I could see having a valid = lifetime since that is fairly straight forward for a DHCP server to enforce). - I believe if you're going to do this properly, you really need an "Identity Association for IPv4 Addresses" option and NOT simply = piggyback IADDR_IPv4 options within an IA_NA or IA_TA. The reason is that then a client has the ability to request that it wants an IPv4 address - if the IA_NA or IA_TA is used, this is not easily done. It also allows the IPv4 addresses to have different T1/T2 times. It also allows a client to = request ONLY IPv4 addresses over DHCPv6 (such as if it is a dual-stack host and = the RA "O" bit is set, so the client would not use DHCPv6 for IPv6 = addresses). In this case, the client simply sends a SOLICIT with only an IA_IPv4 (no IA_TA or IA_NA). I would much prefer we define a methodology for clients to use to = configure information collected from DHCPv4 and DHCPv6. Since all clients that = will use DHCPv6 (and be dual-stacked) will need software updates, asking them = to make some modifications to DHCPv4 should not be completely out of line. In my view, there are two major conditions: a) DHCPv4 and DHCPv6 provide the same value for a particular parameter = (such as domain name search list). In this case, there is no conflict and all = is fine. b) DHCPv4 and DHCPv6 provide different values for a particular = parameter. - In some cases, such as domain name server addresses, this isn't a = major problem. Sure, the ORDER that the information might be used won't be = clear (use IPv4 first, then IPv6, or vice versa, or one, then the other), but = in most cases I can't see this as a major problem. The host should install = both (merged) and use them. - In other cases (such as the domain name), this is a problem. But, the = host might have a means for dealing with it. For example the DHCP servers certainly will if updating DNS with the host's name/address information (DHCPv4 will use the domain name received via it; DHCPv6 will use its). However, the "default domain name" or "dns search list" for the system = would be an issue. In this case, either the user or software must choose. = Perhaps a solution would be to add a DHCPv6 option as to whether the DHCPv6 configuration information should OVERRIDE DHCPv4 information where = conflicts are not otherwise easily resolved? It is extremely interesting to look at the options that were chosen to = be included in draft-cadar-dhc-dhcpv6-v4options-00.txt ... only TWO cover anything that DHCPv4 and DHCPv6 MIGHT both configure - the "DNS Server" = and "Search Domains". And, the DNS Server list is minor since it is very = easy to simple concatenate the DHCPv4 and DHCPv6 list (sure there could be = extremely rare cases where this might not be optimum). The search order is a bit trickier since order could be critical here but this will just be one = option DHCP administrators will need to configure carefully. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Tim Chown Sent: Tuesday, February 10, 2004 5:30 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCP-DHCPv6 Issues and IPv4 options drafts Hi, These two drafts have now been published. As they may not be copied to the dhc list due to their personal status, their summaries are below. The purpose of the drafts is to form a framework for discussion in = Seoul, where Stig Venaas will present the issues draft. Both drafts have a = short slot on the agenda.=20 The main options appear to be keeping the functionality separate, or = adding IPv4 information options to allow only DHCPv6 to be required for = dual-stack nodes. In additional, some "administrative" considerations = could/should be made, e.g. whether or not to use a split name space (*.ipv6.foo.com) for = early IPv6 deployment. Title : IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Author(s) : T. Chown Filename : draft-chown-dhc-dual-stack-00.txt Pages : 10 Date : 2004-2-10 A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4] for IPv6. This document describes issues identified with dual IP version DHCP interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-dhc-dual-stack-00.txt Title : DHCPv6 IPv4 Information Options Author(s) : C. Cadar Filename : draft-cadar-dhc-dhcpv6-v4options-00.txt Pages : 21 Date : 2004-2-10 To ease the management of a site, the Dynamic Host Configuration Protocol (DHCP) is often used. DHCP exists both for the Internet Protocol Version 4 (DHCPv4 for IPv4) and Version 6 (DHCPv6 for IPv6). To avoid possible pitfalls that occur if both DHCP versions are used and to avoid redundancy, IPv4 Information Options may be transmitted using DHCPv6 as described in this document. In dual-stack IPv4/IPv6 scenarios that employ DHCPv6, DHCPv4 can be completely replaced by using the DHCPv6 IPv4 Information Options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cadar-dhc-dhcpv6-v4options-00.t= xt Tim _______________________________________________ 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 Wed Feb 11 22:09:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20551; Wed, 11 Feb 2004 22:09: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 1Ar7Do-0002zf-GG; Wed, 11 Feb 2004 22:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7Dl-0002zU-0y for dhcwg@optimus.ietf.org; Wed, 11 Feb 2004 22:08: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 WAA20522 for ; Wed, 11 Feb 2004 22:08:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7Dh-00061b-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 22:08:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar7Co-0005uj-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 22:07:59 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7CI-0005pT-00 for dhcwg@ietf.org; Wed, 11 Feb 2004 22:07:26 -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 i1C37FGn012924; Wed, 11 Feb 2004 22:07:23 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Mark Stapp'" , "'Ralph Droms'" Cc: Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Wed, 11 Feb 2004 22:07:15 -0500 Message-ID: <000001c3f115$5461f920$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.20040211141458.02466c20@goblet.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 Another point is that these IPR statements don't exactly tell you what = the IP is - and patent lawyers would tell any patent holder that saying any = more is a very bad idea. Patents make multiple claims where the I-D work may = be just one part. While I am with Ted and Barr that I would prefer that there were no = patents especially on pretty basic stuff (or if there are, that they are = "free"), I also understand why companies take the time and effort to patent things = (and believe me, it isn't cheap in terms of time and money - I've been = involved in several patents). So, as long as the IPR statements are aligned with the general IETF guidelines, I don't think we should block forward progress. And, as Mark (and likely others have) pointed out, if we don't like the IETF = guidelines, we should work to get those changed in the proper IETF forum. I'd also prefer that IPR warnings are placed on I-Ds/RFCs. That way, we = at least know that the work is likely to be encumbered. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Mark Stapp Sent: Wednesday, February 11, 2004 3:32 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt=20 where can we go from here? the people who want to stop this draft are=20 basically saying, "we will stop any drafts from people who've agreed to=20 RAND license their IP, and we will stop any drafts as soon as people = other=20 than the authors agree to RAND license their IP." it doesn't seem reasonable to me to expect that each vendor should have = to=20 meet different IPR expectations in response to the different = temperatures=20 of all of the individual working groups. the ietf's consistent overall=20 expectation allows the standards process to continue in a world where=20 intellectual property exists, and allows competing commercial vendors to = contribute. some people in the wg appear to believe that stopping this=20 draft will allow them to make a statement to the ietf which will lead it = to=20 change its expectations in a way that suits them. as someone whose work = has=20 become the victim of this energy, I can only ask again that the people = who=20 object to the ietf's overall expectation address it in the IPR wg. can Ralph or the ADs offer any guidance about whether this kind of storm = has blown up in other groups, and about how we should proceed? -- Mark _______________________________________________ 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 Feb 12 04:13:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15904; Thu, 12 Feb 2004 04:13: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 1ArCu5-00045Y-V3; Thu, 12 Feb 2004 04:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCtb-00044n-C5 for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 04:12: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 EAA15735 for ; Thu, 12 Feb 2004 04:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArCtY-0002zK-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 04:12:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArCsj-0002qR-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 04:11:38 -0500 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1ArCrt-0002gU-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 04:10:45 -0500 Received: from kummerog.uni-muenster.de (kummerog.ipv6.uni-muenster.de [IPv6:2001:638:500:200:210:5aff:fe4c:cfd1]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.10/8.12.9) with ESMTP id i1C9AS4h010696 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 Feb 2004 10:10:34 +0100 (CET) Subject: RE: [dhcwg] DHCP-DHCPv6 Issues and IPv4 options drafts From: Christian Strauf To: Bernie Volz Cc: dhcwg@ietf.org, "'Tim Chown'" In-Reply-To: <000001c3f0f6$0c5e6600$6401a8c0@BVolz> References: <000001c3f0f6$0c5e6600$6401a8c0@BVolz> Content-Type: text/plain; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1076576983.7255.87.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 12 Feb 2004 10:09:43 +0100 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ovaron.join.uni-muenster.de id i1C9AS4h010696 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 Hi Bernie, please find my comments inline. > 1. What advantage is there for configuring IPv4 information into DHCPv6 > servers when the DHCPv4 servers need to be configured anyway to support > IPv4-only hosts. You're still duplicating information. This is true for environments that contain IPv4-only hosts. But for pure dual-stack environments (which are not uncommon and which are likely to be quite common in the near future), you wouldn't need to configure DHCPv4. Please note that the scenarios the IPv4 option draft applies to are not mainly environments that contain IPv4-only hosts if you don't use per-host address assignment. Maybe we should've stressed that some more in the scenarios section. > 2. What happens if there are DHCPv6 servers that don't return IPv4 > information? Does this mean the client can't run IPv4 (since it won't d= o > DHCPv4). This is a configuration issue not an implementation issue in my eyes. > 3. What happens if the IPv6 interface (transport) is started AFTER DHCP= v4 > was used to configure the client? Does the client simply discard the cu= rrent > IPv4 information? What happens if the IPv6 interface (transport) is swi= tched > off? Should the client start DHCPv4 then? A client that uses IPv4 information options in DHCPv6 wouldn't use DHCPv4 at all. Additionally, I don't see why an IPv6 interface would be randomly switched off. If your point is that IPv6 transport is a point of failure when obtaining IPv4 information, then you're right. But I guess DHCP is always a possible point of failure (either if the DHCP server itself or if the connectivity to the server dies) and it makes no significant difference if either the use of DHCPv4 or the use of DHCPv6 is the point of failure. > 4. Unless the DHCPv4 and DHCPv6 servers are able to communicate in some= way > (perhaps they are running in the same image or the DHCPv6 uses DHCPv4 t= o get > leases for clients that need IPv4 addresses), this may result in furthe= r > fragmenting the available IPv4 address space (since now some needs to b= e > allocated to the DHCPv6 server to dole out to dual hosts clients). In m= any > networks, this is probably no big deal; but if addresses are constraine= d ... We were aware of the fragmentation issue when writing the I-D, and I really agree with you that one shouldn't transport IPv4 options with DHCPv6 at the cost of clean IPv4 addressing. But as you said yourself, in many networks, this is not a problem. Especially if you have a fixed IPv4 address assignment on a per-host basis. In this case, you don't have a problem at all. And there's certainly a great number of sites that practise per-host address assignment. In scenarios where you don't have such a fixed assignment, one should refrain from using IPv4 options in DHCPv6 if IPv4-only hosts are expected to be part of the subnet. > I guess we'd all be happy since we'd just say switch to IPv6-only? I take it you're kidding because that's obviously not the intention of the I-D. :-) > The bottom line is that DHCPv4 must continue to exist as long as you ha= ve > IPv4-only or dual stack hosts. It must continue to exist as long as there are IPv4-only hosts, I agree. But using IPv4 options in DHCPv6 for dual-stack hosts reduces the configuration tasks to configuring only one DHCP server. > - Why go through the work of defining DHCPv6 options for every DHCPv4 o= ption > that someone may want? If we go down this road of using DHCPv6 to confi= gure > IPv4, we should just have a single DHCPv6 option that can be used to > encapsulate DHCPv4 options. Note that this encapsulation option may be = used We decided not to use this approach to allow an easier implementation of IPv4 information options in existing DHCPv6 implementations. And I personally don't like the idea of encapsulating DHCPv4 options. > - The IAADDR_IPV4 option is adding new semantics for IPv4 addresses (th= e > lifetimes). This is not a concept IPv4 has had and I'm not sure why we = would > want to introduce this concept (though I could see having a valid lifet= ime > since that is fairly straight forward for a DHCP server to enforce). To be honest, we were not sure whether or not we should stick to the lifetime concept for IPv4 addresses when we submitted the I-D. As you said, it's not so much a problem of implementing it but more a conceptual question. So your input is very welcome because we weren't sure what would be the best approach. > - I believe if you're going to do this properly, you really need an > "Identity Association for IPv4 Addresses" option and NOT simply piggyba= ck > IADDR_IPv4 options within an IA_NA or IA_TA. The reason is that then a > client has the ability to request that it wants an IPv4 address - if th= e > IA_NA or IA_TA is used, this is not easily done. It also allows the IPv= 4 > addresses to have different T1/T2 times. It also allows a client to req= uest > ONLY IPv4 addresses over DHCPv6 (such as if it is a dual-stack host and= the > RA "O" bit is set, so the client would not use DHCPv6 for IPv6 addresse= s). > In this case, the client simply sends a SOLICIT with only an IA_IPv4 (n= o > IA_TA or IA_NA). Interesting point. I need to think it over a little and discuss it with Cristian. > I would much prefer we define a methodology for clients to use to confi= gure > information collected from DHCPv4 and DHCPv6. Since all clients that wi= ll > use DHCPv6 (and be dual-stacked) will need software updates, asking the= m to > make some modifications to DHCPv4 should not be completely out of line. Though you're right when you say that it's not too much to ask to make updates to DHCPv4, I still don't agree. I personally think that one should keep the DHCPv4 and DHCPv6 implementations separate. If you look at DHCP implementations for Unix flavours, for example, I don't see how you can easily make clients decide which information to use from which service. The DHCP implementations are disjoint and making them communicate with each other would be quite tricky in my eyes (please correct me if this was not what you were aiming at). > In my view, there are two major conditions: > a) DHCPv4 and DHCPv6 provide the same value for a particular parameter = (such > as domain name search list). In this case, there is no conflict and all= is > fine. I disagree. As long as one service has no information about the other service, this is exactly the scenario where you get into trouble. Let's take search domain lists as an example. If you get the same search domain list from both DHCPv4 and DHCPv6 and either one service does a reconfigure, it may remove this particular search list, thought the other service still "thinks" that the search list is valid and present. The service does not have the knowledge that the search list information also belongs to the other service. This is one of the reasons why having only one service that transports both IPv4 and IPv6 information is an advantage. > b) DHCPv4 and DHCPv6 provide different values for a particular paramete= r. > - In some cases, such as domain name server addresses, this isn't a maj= or > problem. Sure, the ORDER that the information might be used won't be cl= ear > (use IPv4 first, then IPv6, or vice versa, or one, then the other), but= in > most cases I can't see this as a major problem. The host should install= both > (merged) and use them. You're right, this is not a critical case. > be an issue. In this case, either the user or software must choose. Per= haps > a solution would be to add a DHCPv6 option as to whether the DHCPv6 > configuration information should OVERRIDE DHCPv4 information where conf= licts > are not otherwise easily resolved? This is an interesting point. But then again, if there is a way to transport all information using a single transport protocol (e.g. DHCPv6), that is a much better solution because this will avoid pitfalls when configuring both DHCPv4 and DHCPv6. Accidental overrides wouldn't be possible. And you wouldn't have the administrative overhead of configuring both services for dual-stack hosts (e.g. when doing per-host address assignment). Thank you for your interesting comments. Though you don't like IPv4 information options in DHCPv6, I guess we agree that the issues identified in Tim's draft exist and pose a problem in dual-stack environment and they need to be solved. I still think that IPv4 information options are a possible solution that is not difficult to implement. Cheers, Christian --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 05:42:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18338; Thu, 12 Feb 2004 05:42: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 1ArEIC-0001Hb-Eh; Thu, 12 Feb 2004 05:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArEHS-0001H0-5I for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 05:41: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 FAA18333 for ; Thu, 12 Feb 2004 05:41:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArEHO-0003b7-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 05:41:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArEGV-0003VO-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 05:40:16 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1ArEFh-0003JC-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 05:39:25 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i1CAcn8m006842; Thu, 12 Feb 2004 11:38:49 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i1CAcZsE032705; Thu, 12 Feb 2004 11:38:35 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Feb 2004 11:38:31 +0100 From: Stig Venaas To: Christian Strauf Cc: Bernie Volz , dhcwg@ietf.org, "'Tim Chown'" Subject: Re: [dhcwg] DHCP-DHCPv6 Issues and IPv4 options drafts Message-ID: <20040212103831.GG32618@sverresborg.uninett.no> References: <000001c3f0f6$0c5e6600$6401a8c0@BVolz> <1076576983.7255.87.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1076576983.7255.87.camel@kummerog.uni-muenster.de> User-Agent: Mutt/1.4.1i 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, Feb 12, 2004 at 10:09:43AM +0100, Christian Strauf wrote: > Hi Bernie, > > please find my comments inline. > > > 1. What advantage is there for configuring IPv4 information into DHCPv6 > > servers when the DHCPv4 servers need to be configured anyway to support > > IPv4-only hosts. You're still duplicating information. > This is true for environments that contain IPv4-only hosts. But for pure > dual-stack environments (which are not uncommon and which are likely to > be quite common in the near future), you wouldn't need to configure > DHCPv4. Please note that the scenarios the IPv4 option draft applies to > are not mainly environments that contain IPv4-only hosts if you don't > use per-host address assignment. Maybe we should've stressed that some > more in the scenarios section. I agree very much with this. I know several places where there are pure dual-stack environments now, having to run both DHCPv4 and DHCPv6 is not that nice for managment. Based on situation here at UNINETT, where we have very few IPv4-only and rest dual-stack, here is my take from the managment point of view. Currently DHCPv4 is used, and dual-stack hosts get configuration info from that, except for stateless autoconfiguration for v6 addresses. Being dual stack with more and more services being available also via IPv6, we would like to continue the transition, which means we also need to tell those dual-stack hosts about services with v6 addresses. To do that, we could run both DHCPv4 and DHCPv6, but I don't think the sysadmins would be too happy about that. We could manage without DHCP on the very few dual-stack hosts we have, so running DHCPv6 only would be good, provided that we could learn not only about v6 services, but also services on v4. For some services like say NTP, there could be a mix of v4 and v6 servers. > > 2. What happens if there are DHCPv6 servers that don't return IPv4 > > information? Does this mean the client can't run IPv4 (since it won't do > > DHCPv4). > This is a configuration issue not an implementation issue in my eyes. > > > 3. What happens if the IPv6 interface (transport) is started AFTER DHCPv4 > > was used to configure the client? Does the client simply discard the current > > IPv4 information? What happens if the IPv6 interface (transport) is switched > > off? Should the client start DHCPv4 then? This is a theoretic possibility, but not common I think. I'm not sure what best behaviour would be though. [...] > > - Why go through the work of defining DHCPv6 options for every DHCPv4 option > > that someone may want? If we go down this road of using DHCPv6 to configure > > IPv4, we should just have a single DHCPv6 option that can be used to > > encapsulate DHCPv4 options. Note that this encapsulation option may be used > We decided not to use this approach to allow an easier implementation of > IPv4 information options in existing DHCPv6 implementations. And I > personally don't like the idea of encapsulating DHCPv4 options. I'm not sure of all the implications in the protocol, but to me encapsulation sounds reasonable. Else you'll have either only a few v4 options available, or you would need to put out new specifications for many of them. I don't know if it's an issue, but on both server and client, there might be a possible to have some common code, image or process for doing both DHCPv4 and DHCPv6, especially in the client, it could be nice to have a minimal client supporting both I think. The question I have then, is whether it's easier to reuse client code if the options are simply embedded. Could this make the client footprint smaller? Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 08:29:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23061; Thu, 12 Feb 2004 08:29: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 1ArGto-0002Me-VF; Thu, 12 Feb 2004 08:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGtE-0002JO-87 for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 08:28:24 -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 IAA23021 for ; Thu, 12 Feb 2004 08:28:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArGt9-0003cH-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:28:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArGsG-0003Wm-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:27:25 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1ArGrv-0003Ql-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:27:03 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id 45B2A1C01620 for ; Thu, 12 Feb 2004 08:27:03 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1CCxLZ17673 for ; Thu, 12 Feb 2004 18:29:21 +0530 (IST) Message-ID: <402B7F1B.30402@india.hp.com> Date: Thu, 12 Feb 2004 18:56:51 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: DHCPWG Content-Type: text/plain; charset=ISO-8859-1; 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] Dual stack issues 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 My quick comments about the draft.... I beleieve the main concern raised in the draft is, how to handle the service parameters obtained from DHCPv6 and DHCPv4. I really see that this is a configuration issue rather than the protocol issue.. Every IPv4 service addresses can be sent as IPv4 mapped IPv6 addresses in the DHCPv6.. So, the client will always able to get the IPv4 configuration, What the admin needs to do is to make sure that these parameters are not configured in both DHCPv4 and DHCPv6. In this way, the dhcp clients doesn't need to merge/choose the lists. Remember the discussion about nisconfig in the wg list, kre rightly said that you could change the protocol for merging DHCPv4 and DHCPv6 information. But, it is not really possible if you are getting the parameters from someother source, eg:- SLP. In this way the problem exists still. So, I guess the best way to deal with the issue, rather than duplicating dhcpv4 options, its good to refer as IPv4 mapped IPv6 addresses. But still I am not convinced with sending IPv4 information in DHCPv6, even as IPv4 mapped IPv6 addresses. DHCPv4 should give v4 parameters and dhcpv6 should give v6 parameters. They should be disjoint list configured by an intelligent admin. Thats it. Then regarding DHCPv6 server giving v4 addresses, its not really a good idea. Its just thrusting the DHCPv4 functionality in DHCPv6. Instead running dhcpv4 and dhcpv6 clients seperately, you are going to run an overloaded dhcpv6 client.I couldn't get a reason why there should be single dhcpclient. Am I missing something here? ~ Vijay -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 08:32:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23164; Thu, 12 Feb 2004 08:32: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 1ArGwj-0002eE-6i; Thu, 12 Feb 2004 08:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGw2-0002ah-7R for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 08:31: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 IAA23113 for ; Thu, 12 Feb 2004 08:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArGvx-0003wS-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:31:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArGv6-0003qN-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:30:21 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1ArGuK-0003kK-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:29:32 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel7.hp.com (Postfix) with ESMTP id 13DD41C01998 for ; Thu, 12 Feb 2004 08:29:33 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1CD1pZ18251 for ; Thu, 12 Feb 2004 18:31:51 +0530 (IST) Message-ID: <402B7FB1.9060504@india.hp.com> Date: Thu, 12 Feb 2004 18:59:21 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: DHCPWG Content-Type: multipart/mixed; boundary="------------090002080503090806010606" 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] [Fwd: Re: Dual stack issues] 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. --------------090002080503090806010606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I thought it will be good to include the list also in this discussions. ~ Vijay --------------090002080503090806010606 Content-Type: message/rfc822; name="Re: Dual stack issues" Content-Disposition: inline; filename="Re: Dual stack issues" Message-ID: <402B7EC0.6010907@india.hp.com> Date: Thu, 12 Feb 2004 18:55:20 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas CC: tjc@ecs.soton.ac.uk, strauf@uni-muenster.de, Ralph , cristian.cadar@netlab.nec.de Subject: Re: Dual stack issues References: <402B6D8E.2040304@india.hp.com> <20040212123007.GL32618@sverresborg.uninett.no> In-Reply-To: <20040212123007.GL32618@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stig Venaas wrote: >On Thu, Feb 12, 2004 at 05:41:58PM +0530, Vijayabhaskar A K wrote: >[...] > > >>Then regarding DHCPv6 server giving v4 addresses, its not really a good >>idea. Its just thrusting the DHCPv4 functionality in DHCPv6. Instead >>running dhcpv4 and dhcpv6 clients seperately, you are going to run an >>overloaded dhcpv6 client.I couldn't get a reason why there should be >>single dhcpclient. Am I missing something here? >> >> > >I think we have some fundamentally different views. > >I know it can get complicated etc. but in general without looking at >the technical details, I would say that which DHCP protocol is used >(whether it's over v4 or v6) shouldn't affect what kind of addresses >you can get configured with it. Although none of us would propose >getting v6 with DHCPv4 I'm sure (: > > There is nothing wrong in it.. But, the real requirement is important >As another example, what if I'm running say Apple Talk, and I wanted >to learn the AT address for a service, or some configuration parameter, >wouldn't that be something DHCP could do as well? > >The fundamental problem for me anyway, is dual-stack hosts, which we >will have for at least next 10 years if you ask me, probably longer. >We want to start migrating to IPv6 services, but some will remain in >IPv4 for some years. Should I then be forced to run both DHCPv4 AND >DHCPv6, and also have dual-stack hosts do BOTH DHCPv4 and DHCPv6? > > Please remember that, DHCPv4 is not just another application which *just uses* IPv4 addresses... They *provide* IPv4 addresses. They are indispensable unit in IPv4.. You need IPv4 router and IPv4 stack till there is a last node supporing IPv4 exists.. DHCPv4 is also very similar to this. Let both versions of DHCPv4 and DHCPv6 exist together >To me that sounds pretty broken. There's a lot of extra managment >and failure possibilities. > > As I said earlier, intelligent configuration of network will solve the problems stated, there is no need of protocol changes.. Moreover, extra management and failure possibilities will be more, only in the case,if we merge it together.. Some of the issues has been already sent by Bernie.. >Doing also IPv4 with DHCPv6 is a relatively simple addition I think. >You need a new option for the address delegation, and one for doing >encapsulation. Isn't that all? There might be complications I'm not >aware of. > > client needs to do an ARP, some servers also do ARP check. Similar needs will arise and it really make dhcpv6 heavier and will lead to lot more implementation issues.. >Then, I would say that hosts that have IPv6 support should try >DHCPv6 query, if it works fine. If not, fall back to do DHCPv4. > > Well, you can do it as different entity rather than a single dhcpclient application.. >Of course it should also be possible for administrator or user >to choose witch one to use, and whether to fall back. > >Shouldn't we have this discussion on the list? > > I want to make sure whether my understanding is correct or not.. I didn't want to create a mess in WG with my wrong assumption and there is a chance of the discussion drifting away from the topic.. Anyhow, I will post it in WG list... ~ Vijay >Stig > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ --------------090002080503090806010606-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 08:51:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23889; Thu, 12 Feb 2004 08:51: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 1ArHF7-0004Hg-Ey; Thu, 12 Feb 2004 08: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 1ArHEN-0004Fq-SI for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 08:50:15 -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 IAA23862 for ; Thu, 12 Feb 2004 08:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHEI-0005qK-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:50:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHDM-0005ko-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:49:12 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1ArHCg-0005au-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 08:48:30 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i1CDm08m030713; Thu, 12 Feb 2004 14:48:00 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i1CDm1u4000482; Thu, 12 Feb 2004 14:48:01 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Feb 2004 14:48:01 +0100 From: Stig Venaas To: Vijayabhaskar A K Cc: DHCPWG Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] Message-ID: <20040212134801.GQ32618@sverresborg.uninett.no> References: <402B7FB1.9060504@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402B7FB1.9060504@india.hp.com> User-Agent: Mutt/1.4.1i 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, Feb 12, 2004 at 06:59:21PM +0530, Vijayabhaskar A K wrote: > Stig Venaas wrote: [...] > Please remember that, DHCPv4 is not just another application which *just > uses* IPv4 addresses... They *provide* IPv4 addresses. They are > indispensable unit in IPv4.. You need IPv4 router and IPv4 stack till > there is a last node supporing IPv4 exists.. DHCPv4 is also very similar > to this. Let both versions of DHCPv4 and DHCPv6 exist together I'm of course not saying that DHCPv4 should stop to exist. But in a dual-stack environment, I think it's cleaner to get the v4 addresses from the DHCPv6 server, and not be forced to manage both. [...] > As I said earlier, intelligent configuration of network will solve the > problems stated, there is no need of protocol changes.. Moreover, extra > management and failure possibilities will be more, only in the case,if > we merge it together.. Some of the issues has been already sent by Bernie.. If you need both servers to configure interfaces with addresses, and get other configuration, then you rely on two separate protocols to work (servers and relays etc) in order for the host to behave correctly. > >Doing also IPv4 with DHCPv6 is a relatively simple addition I think. > >You need a new option for the address delegation, and one for doing > >encapsulation. Isn't that all? There might be complications I'm not > >aware of. > > > > > client needs to do an ARP, some servers also do ARP check. Similar needs > will arise and it really make dhcpv6 heavier and will lead to lot more > implementation issues.. Of course it could be up to the vendor whether they also want to support delegation of v4 addresses. And the administrator can perhaps choose whether to use it, and maybe choose between different versions. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 09:05:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24288; Thu, 12 Feb 2004 09:05: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 1ArHSf-0005G2-6G; Thu, 12 Feb 2004 09:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHRv-0005F4-KJ for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 09:04:15 -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 JAA24244 for ; Thu, 12 Feb 2004 09:04:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHRq-00072t-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 09:04:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHQq-0006xh-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 09:03:09 -0500 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1ArHPt-0006si-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 09:02:09 -0500 Received: from kummerog.uni-muenster.de (kummerog.ipv6.uni-muenster.de [IPv6:2001:638:500:200:210:5aff:fe4c:cfd1]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.10/8.12.9) with ESMTP id i1CE1x4h013075 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 Feb 2004 15:02:05 +0100 (CET) Subject: Re: [dhcwg] Dual stack issues From: Christian Strauf To: Vijayabhaskar A K Cc: DHCPWG In-Reply-To: <402B7F1B.30402@india.hp.com> References: <402B7F1B.30402@india.hp.com> Content-Type: text/plain; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1076594479.7255.115.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 12 Feb 2004 15:01:19 +0100 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ovaron.join.uni-muenster.de id i1CE1x4h013075 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 Hi Vijay! I agree with Stig in his mail (Stig: could you be so kind a post your response to the list? tnx!) saying that we have fundamentally different views. Having DHCPv4 only convey v4 information and DHCPv6 only v6 information is only one view. Another view is to regard DHCPv6 merely as means of transport. If I remember correctly, there's no statement in RFC 3315 saying that you must only transport IPv6 information with DHCPv6. Additionally, there are a number of paradigms in DHCPv6 that we miss in DHCPv4 in our day to day operations, e.g. going away from using MACs for per-host address assignment but instead use DUIDs/IAIDs etc.. I see a real gain of administrative comfort in using DHCPv6 for transporting IPv4 information. > eg:- SLP. In this way the problem exists still. So, I guess the best wa= y=20 > to deal with the issue, rather than duplicating dhcpv4 options, its goo= d=20 > to refer as IPv4 mapped IPv6 addresses. But still I am not convinced=20 There're cases where this is not desirable e.g. when using broadcast address options for IPv4 which only make sense as suboptions of OPTION_IAADDR_IPv4. > parameters. They should be disjoint list configured by an intelligent=20 > admin. Thats it. Well, from an admin's point of view it's practical to only have to administrate DUIDs and IAIDs for dual-stack hosts, not MAC addresses as well. > overloaded dhcpv6 client.I couldn't get a reason why there should be=20 > single dhcpclient. Am I missing something here? The issues listed in draft-chown-dhc-dual-stack-00 can be solved by having such a single client. Putting aside whether this is a pure DHCPv6 client that can request IPv4 information options or if it is a combined DHCPv4/-v6 client, it is an elegant solution to the problems outlined there. Cheers, Christian --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 10:06:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26270; Thu, 12 Feb 2004 10:06: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 1ArIPh-0004h3-3a; Thu, 12 Feb 2004 10: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 1ArIOx-0004UM-8r for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 10:05:15 -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 KAA26114 for ; Thu, 12 Feb 2004 10:05:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArIOr-0004mu-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 10:05:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArINt-0004h5-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 10:04:09 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1ArIMx-0004bO-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 10:03:11 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel12.hp.com (Postfix) with ESMTP id 6E20A1C00825; Thu, 12 Feb 2004 07:03:11 -0800 (PST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1CEZPZ07107; Thu, 12 Feb 2004 20:05:25 +0530 (IST) Message-ID: <402B95A4.7060408@india.hp.com> Date: Thu, 12 Feb 2004 20:33:00 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas Cc: DHCPWG Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] References: <402B7FB1.9060504@india.hp.com> <20040212134801.GQ32618@sverresborg.uninett.no> In-Reply-To: <20040212134801.GQ32618@sverresborg.uninett.no> Content-Type: text/plain; charset=ISO-8859-1; 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 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 Stig Venaas wrote: >On Thu, Feb 12, 2004 at 06:59:21PM +0530, Vijayabhaskar A K wrote: > > >>Stig Venaas wrote: >> >> >[...] > > >>Please remember that, DHCPv4 is not just another application which *just >>uses* IPv4 addresses... They *provide* IPv4 addresses. They are >>indispensable unit in IPv4.. You need IPv4 router and IPv4 stack till >>there is a last node supporing IPv4 exists.. DHCPv4 is also very similar >>to this. Let both versions of DHCPv4 and DHCPv6 exist together >> >> > >I'm of course not saying that DHCPv4 should stop to exist. But in a >dual-stack environment, I think it's cleaner to get the v4 addresses >from the DHCPv6 server, and not be forced to manage both. > > Stateless address autoconf doesn't advertise IPv4 prefixes.. Why should DHCPv6 support IPv4 configuration? >[...] > > >>As I said earlier, intelligent configuration of network will solve the >>problems stated, there is no need of protocol changes.. Moreover, extra >>management and failure possibilities will be more, only in the case,if >>we merge it together.. Some of the issues has been already sent by Bernie.. >> >> > >If you need both servers to configure interfaces with addresses, and >get other configuration, then you rely on two separate protocols to >work (servers and relays etc) in order for the host to behave correctly. > > Well, you need IPv4 router, IPv4 stack, applications understanding IPv4 and lot more for IPv4 to work.. Its just a configuration.. Already all the DHCPv4 components exist and you need to just configure.. In your case also admin has to configure both... > > >>>Doing also IPv4 with DHCPv6 is a relatively simple addition I think. >>>You need a new option for the address delegation, and one for doing >>>encapsulation. Isn't that all? There might be complications I'm not >>>aware of. >>> >>> >>> >>> >>client needs to do an ARP, some servers also do ARP check. Similar needs >>will arise and it really make dhcpv6 heavier and will lead to lot more >>implementation issues.. >> >> > >Of course it could be up to the vendor whether they also want to >support delegation of v4 addresses. And the administrator can >perhaps choose whether to use it, and maybe choose between different >versions. > > The question is whether to give that flexibility or not. IPv4 is going to die one day. Whatever you are trying to define will give an uglier or complicated look to dhcpv6 on that day. The key fact is you *can* configure IPv4 stack *without* requiring DHCPv6. The gains you get by duplicating all these functionalities in DHCPv6 is much lesser. Even it is not worth time investing in duplicating IPv4 configuration in DHCPv6. ~ Vijay >Stig > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 11:07:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00085; Thu, 12 Feb 2004 11:07: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 1ArJMj-0005te-R1; Thu, 12 Feb 2004 11: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 1ArJMA-0005nV-AG for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 11:06:26 -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 LAA00041 for ; Thu, 12 Feb 2004 11:06:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJM3-0003mH-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:06:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJLG-0003gk-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:05:31 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1ArJKZ-0003Xx-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:04:47 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1CG4GjT000472 for ; Thu, 12 Feb 2004 17:04:17 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1CG4CrL000470 for ; Thu, 12 Feb 2004 17:04:12 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1CG4BjR000467; Thu, 12 Feb 2004 17:04:12 +0100 (CET) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 101C58BBE8; Thu, 12 Feb 2004 17:04:11 +0100 (CET) From: Cristian Cadar Organization: NEC Europe Ltd. To: Vijayabhaskar A K Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] Date: Thu, 12 Feb 2004 17:04:56 +0100 User-Agent: KMail/1.5.4 References: <402B7FB1.9060504@india.hp.com> <20040212134801.GQ32618@sverresborg.uninett.no> <402B95A4.7060408@india.hp.com> In-Reply-To: <402B95A4.7060408@india.hp.com> Cc: DHCPWG MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402121704.56555.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 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 Hi Vijay! On Thursday 12 February 2004 16:03, Vijayabhaskar A K wrote: > Stig Venaas wrote: > >On Thu, Feb 12, 2004 at 06:59:21PM +0530, Vijayabhaskar A K wrote: > >>Stig Venaas wrote: > > > >[...] > > > >>Please remember that, DHCPv4 is not just another application which *just > >>uses* IPv4 addresses... They *provide* IPv4 addresses. They are > >>indispensable unit in IPv4.. You need IPv4 router and IPv4 stack till > >>there is a last node supporing IPv4 exists.. DHCPv4 is also very similar > >>to this. Let both versions of DHCPv4 and DHCPv6 exist together > > > >I'm of course not saying that DHCPv4 should stop to exist. But in a > >dual-stack environment, I think it's cleaner to get the v4 addresses > >from the DHCPv6 server, and not be forced to manage both. > > Stateless address autoconf doesn't advertise IPv4 prefixes.. Why should > DHCPv6 support IPv4 configuration? > > >[...] > > > >>As I said earlier, intelligent configuration of network will solve the > >>problems stated, there is no need of protocol changes.. Moreover, extra > >>management and failure possibilities will be more, only in the case,if > >>we merge it together.. Some of the issues has been already sent by > >> Bernie.. > > > >If you need both servers to configure interfaces with addresses, and > >get other configuration, then you rely on two separate protocols to > >work (servers and relays etc) in order for the host to behave correctly. > > Well, you need IPv4 router, IPv4 stack, applications understanding IPv4 > and lot more for IPv4 to work.. Its just a configuration.. Already all > the DHCPv4 components exist and you need to just configure.. In your > case also admin has to configure both... > > >>>Doing also IPv4 with DHCPv6 is a relatively simple addition I think. > >>>You need a new option for the address delegation, and one for doing > >>>encapsulation. Isn't that all? There might be complications I'm not > >>>aware of. > >> > >>client needs to do an ARP, some servers also do ARP check. Similar needs > >>will arise and it really make dhcpv6 heavier and will lead to lot more > >>implementation issues.. > > > >Of course it could be up to the vendor whether they also want to > >support delegation of v4 addresses. And the administrator can > >perhaps choose whether to use it, and maybe choose between different > >versions. > > The question is whether to give that flexibility or not. IPv4 is going > to die one day. Whatever you are trying to define will give an uglier or > complicated look to dhcpv6 on that day. The key fact is you *can* > configure IPv4 stack *without* requiring DHCPv6. The gains you get by > duplicating all these functionalities in DHCPv6 is much lesser. Even it > is not worth time investing in duplicating IPv4 configuration in DHCPv6. We are trying to draw a line between the configuration of clients with only v4 stack and clients with dual stack , the first to be configured by the dhcpv4 and the latter only by the dhcpv6 avoiding the dual stack clients to be configured by both dhcpv4 and dhcpv6 which could create some problems latter(in this way there is less overhead for the admin to mantain the v4 and v6 networks at the same time). As it was outlined in the draft these modifications have only a small inpact on the dhcpv6 stack , on the day when IPv4 will die the options for carring ipv4 opt will be declared obsolete . Cheers Cristian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 11:13:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00356; Thu, 12 Feb 2004 11:13: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 1ArJSU-0006ZR-DM; Thu, 12 Feb 2004 11:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJRt-0006Yu-Et for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 11:12: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 LAA00336 for ; Thu, 12 Feb 2004 11:12:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJRq-0004LX-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:12:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJQr-0004GP-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:11:18 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1ArJQG-0004Bu-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:10:41 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel10.hp.com (Postfix) with ESMTP id B80F91C022FB; Thu, 12 Feb 2004 08:10:38 -0800 (PST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1CFgnZ19007; Thu, 12 Feb 2004 21:12:50 +0530 (IST) Message-ID: <402BA572.70002@india.hp.com> Date: Thu, 12 Feb 2004 21:40:26 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Strauf Cc: DHCPWG Subject: Re: [dhcwg] Dual stack issues References: <402B7F1B.30402@india.hp.com> <1076594479.7255.115.camel@kummerog.uni-muenster.de> In-Reply-To: <1076594479.7255.115.camel@kummerog.uni-muenster.de> Content-Type: text/plain; charset=ISO-8859-15; 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 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 Christian comments inline.. Christian Strauf wrote: >Hi Vijay! > >I agree with Stig in his mail (Stig: could you be so kind a post your >response to the list? tnx!) saying that we have fundamentally different >views. Having DHCPv4 only convey v4 information and DHCPv6 only v6 >information is only one view. Another view is to regard DHCPv6 merely as >means of transport. If I remember correctly, there's no statement in RFC >3315 saying that you must only transport IPv6 information with DHCPv6. > > It doesn't matter whether it can be done or not. The real need is important.. I couldn't see an actual problem here. >Additionally, there are a number of paradigms in DHCPv6 that we miss in >DHCPv4 in our day to day operations, e.g. going away from using MACs for >per-host address assignment but instead use DUIDs/IAIDs etc.. I see a >real gain of administrative comfort in using DHCPv6 for transporting >IPv4 information. > > > >>eg:- SLP. In this way the problem exists still. So, I guess the best way >>to deal with the issue, rather than duplicating dhcpv4 options, its good >>to refer as IPv4 mapped IPv6 addresses. But still I am not convinced >> >> >There're cases where this is not desirable e.g. when using broadcast >address options for IPv4 which only make sense as suboptions of >OPTION_IAADDR_IPv4. > > Though I am saying that the IPv4 service parameters can be given as IPv4 mapped IPv6 addresses, I really dont like the idea of doing it. With a proper configuration of DHCPv4 and DHCPv6 server, you can acheive whatever the dual stack host need. Here, all the DHCPv4 address configuration (other than service parameters) should be done by DHCPv4 > > >>parameters. They should be disjoint list configured by an intelligent >>admin. Thats it. >> >> >Well, from an admin's point of view it's practical to only have to >administrate DUIDs and IAIDs for dual-stack hosts, not MAC addresses as >well. > > I guess some work is going on in this area. Rather than porting all the IPv4 configuration to DHCPv6, backporting of just a single feature makes more sense. > > >>overloaded dhcpv6 client.I couldn't get a reason why there should be >>single dhcpclient. Am I missing something here? >> >> >The issues listed in draft-chown-dhc-dual-stack-00 can be solved by >having such a single client. Putting aside whether this is a pure DHCPv6 >client that can request IPv4 information options or if it is a combined >DHCPv4/-v6 client, it is an elegant solution to the problems outlined >there. > > Let me go through the list.. I have listed my comments along with the text from draft-chown-dhc-dual-stack-00 >3.1 Handling multiple responses > > The general question is how to handle configuration information that > may be gathered from multiple sources. Where those sources are DHCP > and DHCPv6 servers (which may be two physical nodes or two servers > running on the same node) the client node needs to know whether to > use the most recent data, or whether to perform some merger or union > of the responses by certain rules. A node may choose to ask a DHCPv6 > server and only use a DHCP server if no response is received. > Its a configuration issue.... Make DHCPv6 to send IPv6 params and DHCPv4 to send IPv4 params. Always the client needs to combine the list. >Merging is possible, but is likely to be complex. > > It is not at all complex when the lists are disjoint. >A node configured manually to use an IPv6 DNS server via > such manual configuration may lose that configuration if it then uses > DHCP to obtain IPv4 settings if in a dual-stack environment; > The problem exists even with your solution. Moreover, this is not protocol issue. The admin can define the order. >3.2 Multiple interfaces > >Per interface settings can be complex because a client node needs to > know from which interface system settings like NTP server came from. > And it may not be apparent which setting should be used, if e.g. an > NTP server option is received on multiple interfaces, potentially > over different protocols. > > NTP server is not a per interface settings. It doesn't matter from which interface it came from. The router will take care where to forward if there is a NTP request for a particular server. >3.3 DNS load balancing > > In some cases it is preferable to list DNS server information in an > ordered way per node for load balancing, giving different responses > to different clients. Responses from different DHCP and DHCPv6 > servers may make such configuration problematic. > Here you need a mix up of ordering.. Use DHCPv6, since it can give IPv4 addresses as IPv4 mapped IPv6 addresses. >3.4 DNS search path issues This falls in same category as the prev one. Do specify the search order, thats it. >3.5 Administrative management > It could be termed as configuration issue.. Needed to be fixed this in administration rather than protocols. >3.6 DHCP option variations > use DHCPv6, send IPv4 mapped IPv6 addresses. I really couldn't see the difficulties in the configuration of dual stack nodes. Without the clear problem statement, I am not able to co-relate the solution you propose. May be, I am missing somethings. Comments are welcomed. ~ Vijay >Cheers, >Christian > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 11:31:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01186; Thu, 12 Feb 2004 11:31: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 1ArJjx-00081p-0D; Thu, 12 Feb 2004 11:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJjM-0007zv-HK for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 11:30:24 -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 LAA01124 for ; Thu, 12 Feb 2004 11:30:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJjJ-0006LF-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:30:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJiM-0006Am-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:29:23 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1ArJhX-0005ue-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:28:31 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i1CGS18m011911; Thu, 12 Feb 2004 17:28:01 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i1CGS1t7000717; Thu, 12 Feb 2004 17:28:01 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Feb 2004 17:28:01 +0100 From: Stig Venaas To: Vijayabhaskar A K Cc: Christian Strauf , DHCPWG Subject: Re: [dhcwg] Dual stack issues Message-ID: <20040212162801.GB679@sverresborg.uninett.no> References: <402B7F1B.30402@india.hp.com> <1076594479.7255.115.camel@kummerog.uni-muenster.de> <402BA572.70002@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402BA572.70002@india.hp.com> User-Agent: Mutt/1.4.1i 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 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 think it boils down to two alternatives. Dual-stack hosts using both DHCPv4 and DHCPv6 Dual-stack hosts getting necessary v4 info from DHCPv6 Or actually, there's sort of a middle solution of DHCPv6 being able to specify v4 addresses in some options, but not leasing out v4 addresses for the host configuration. Perhaps should try to write down how things can be done in the different cases, and then try to compare them? Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 11:50:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02064; Thu, 12 Feb 2004 11:50: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 1ArK2L-0001pm-R1; Thu, 12 Feb 2004 11:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK1g-0001kZ-Cu for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 11:49:20 -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 LAA01965 for ; Thu, 12 Feb 2004 11:49:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArK1d-0000iI-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:49:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArK0i-0000cy-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:48:20 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1ArK06-0000Xv-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 11:47:42 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel9.hp.com (Postfix) with ESMTP id EFBE51C013E6; Thu, 12 Feb 2004 11:47:41 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i1CGJpZ25881; Thu, 12 Feb 2004 21:49:51 +0530 (IST) Message-ID: <402BAE22.2070209@india.hp.com> Date: Thu, 12 Feb 2004 22:17:30 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas Cc: Christian Strauf , DHCPWG Subject: Re: [dhcwg] Dual stack issues References: <402B7F1B.30402@india.hp.com> <1076594479.7255.115.camel@kummerog.uni-muenster.de> <402BA572.70002@india.hp.com> <20040212162801.GB679@sverresborg.uninett.no> In-Reply-To: <20040212162801.GB679@sverresborg.uninett.no> 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 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 Stig Venaas wrote: >I think it boils down to two alternatives. > >Dual-stack hosts using both DHCPv4 and DHCPv6 > >Dual-stack hosts getting necessary v4 info from DHCPv6 > >Or actually, there's sort of a middle solution of DHCPv6 being >able to specify v4 addresses in some options, but not leasing >out v4 addresses for the host configuration. > >Perhaps should try to write down how things can be done in the >different cases, and then try to compare them? > > Yes. It is better to do. One of them will be a solution for the recent nisconfig and other configuration parameters options' problem in dual stack environment. >Stig > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-22053085 Hewlett Packard Mobile: +91-9845241382 Bangalore, India Email : vijayak@india.hp.com Intellectuals solve problems: geniuses prevent them. -Albert Einstein, physicist, Nobel laureate (1879-1955) __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 13:06:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04920; Thu, 12 Feb 2004 13:06: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 1ArLDt-0002U1-OG; Thu, 12 Feb 2004 13: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 1ArLDG-0002Ru-P5 for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 13:05:22 -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 NAA04881 for ; Thu, 12 Feb 2004 13:05:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLDD-0000vD-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 13:05:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLCK-0000pc-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 13:04:24 -0500 Received: from smtp013.mail.yahoo.com ([216.136.173.57]) by ietf-mx with smtp (Exim 4.12) id 1ArLBl-0000kb-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 13:03:49 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp013.mail.yahoo.com with SMTP; 12 Feb 2004 18:03:50 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 12 Feb 2004 10:08:28 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20040211141458.02466c20@goblet.cisco.com> Importance: 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 > -----Original Message----- > From: Mark Stapp > Sent: Wednesday, February 11, 2004 12:32 > > where can we go from here? the people who want to stop this draft are > basically saying, "we will stop any drafts from people who've agreed to > RAND license their IP, and we will stop any drafts as soon as people other > than the authors agree to RAND license their IP." > ...Mark, you've missed my objection: I was trying to say that while only the IETF as a whole can address IPR issues (and believe me, NO ONE would want a situation where every single WG or worse, every RFC had different IPR terms and conditions) the "reasonable and non-discriminatory" terms may be very difficult or impossible for some vendors to meet. While Ted is not personally the owner of the ISC DHCPD implementation, imagine if he were, and that there were just 3 verified IPR claims against DHCPD based on patents, trade secrets, copyrights, or other mechanisms. Let's continue by assuming that each "reasonable" license term called for the payment of $1 for each copy distributed. So, $3 per copy, what's the big deal? Given that Ted would probably be distributing DHCPD as open-source freeware initially, with anonymous FTP used for distribution, that distribution model would have to end and copies distributed for, say, $3.95 each. The extra charge is necessary to pay for the entire e-commerce application required to register downloads, collect money to pay the license holders, and to build up a reserve to defend himself when one of his customers illicitly copies the distribution and shares it without license fees flowing back to the IPR holders. There is no way, in my opinion, to protect oneself from every possible threat concerning the use of someone else's IPR when license terms include such vague (and potentially meaningless) language as "reasonable and non-discriminatory." I won't pretend to be an expert on torts, patent and copyright law, or IPR, but I have been on serveral civil juries deciding breach of contract suits, nearly all turning on the question of whether one party or the other truly possessed rights to some property or compensation. In my limited experience, unless the holder of some valuable commodity vigorously and frequently defends their rights, juries (at least in California and New York) seem overwhelmingly to determine that while they may have had rights "de jure" their inaction defending those rights resulted in a "de facto" abandonment of those rights. So not only does a small vendor have to maintain an e-commerce site and collect monies to pay IPR license holders in my example, the vendor must also vigorously seek out and prosecute those who abuse or ignore the terms of the vendor's license agreement (instituted to protect the IPR holders among other reasons.) So that $3.95 download and usage license fee is probably too small by an order of magnitude. Imagine if the Free Software Foundation's C/C++ compilers and related tools were suddenly burdened with license fees, no matter how modest, for a variety of IPR holders. > it doesn't seem reasonable to me to expect that each vendor should have to > meet different IPR expectations in response to the different temperatures > of all of the individual working groups. the ietf's consistent overall > expectation allows the standards process to continue in a world where > intellectual property exists, and allows competing commercial vendors to > contribute. some people in the wg appear to believe that stopping this > draft will allow them to make a statement to the ietf which will > lead it to change its expectations in a way that suits them. as someone > whose work has become the victim of this energy, I can only ask again that > the people who object to the ietf's overall expectation address it in the > IPR wg. > ...you're right, Mark... there should be only one IPR license agreement for all uses under the guise of IETF, from building commercial or open-source products to discussing or teaching the technology, and it should meet nearly impossible criteria: (1) it should be generic enough not to limit an IPR holder's claims as circumstances and technology changes, (2) it should be specific enough so that no vendor is left struggling to determine exactly what uses are permitted (including derivative products) or what are the terms for use, and (3) it needs to offer protection to a vendor if their products are illicitly copied and distributed (effectively holding them harmless against IPR license claims for misuse of products based on or including someone else's protected intellectual property.) I remember the Chicago meeting, when the Relay Agent Information Option nearly lost it's support from the working group because of Motorola's IPR claims. My memory was a bit faulty, as I had thought that Motorola had agreed to the same IPR limitations as had all other IPR holders whose technologies had been used in RFCs. I'm surprised to learn today that they were held to a stricter term. I don't think this is a good idea at all. I do think that we need one solution which addresses the concerns raised in this message exchange, and as much as I don't want to stomp on your work, which I'm sure was done innocent of any knowledge of using someone else's IPR, I fully believe that it is in the best interest of all IETF contributors to resolve the issues Ted raised. Finally, as far as the much-delayed DHCP server MIB is concerned, you are completely correct: I would be thoroughly disingenuous if I applied a different standard to my contributions than to those of others. I'm not going to withdraw the draft until I've learned more about how IBM's patent on "Network Alert Message Construction" has actually affected SNMP implementers, but a quick web search turned up several SNMP agent and manager implementations whose licenses make copyright claims, but none that even acknowledge the IBM patent. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 13:16:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05451; Thu, 12 Feb 2004 13:16: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 1ArLNY-0004h7-Sz; Thu, 12 Feb 2004 13:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLMz-0004fi-Qp for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 13:15:26 -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 NAA05396 for ; Thu, 12 Feb 2004 13:15:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLMv-0002Bp-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 13:15:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLM1-00025P-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 13:14:26 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1ArLLD-0001xo-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 13:13:35 -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 i1CIDQGn098302; Thu, 12 Feb 2004 13:13:36 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Vijayabhaskar A K'" , "'Stig Venaas'" Cc: "'Christian Strauf'" , "'DHCPWG'" Subject: RE: [dhcwg] Dual stack issues Date: Thu, 12 Feb 2004 13:13:27 -0500 Message-ID: <000501c3f193$eaa0a930$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 In-Reply-To: <402BAE22.2070209@india.hp.com> 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: 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 I think the first step is to identify those items that are going to be = an issue. First, we need to look at the types of data: a. Single values. When a single value for a configuration item exists, obviously if the DHCPv4 and DHCPv6 supplied values differ, there is a = major problem. Worse, if the DHCPv4 and DHCPv6 clients don't in some way have = a consist policy for updating the client's configuration the value may flip-flop depending on which client last received configuration = information. b. List of values. When a configuration item can be a list of values (typically the first listed item is preferred), the significant issues = are: - Is merging the lists proper? - When both DHCPv4/v6 configure values, how should the values be ordered when merged? - When there is a limit to the number of configured values that may be allowed, what happens if the combined DHCPv4/v6 configured values exceed this limit? If the values are simply concatenated, it is possible that = one transport's values may not be added (because the other fills the = available slots). c. Incompatible configuration values. It may be that for some = configuration items, DHCPv6 supplies domain names (such the SMTP or POP servers) = whereas DHCPv4 provided only IPv4 addresses. But, I think this is any different = from (b) because if a host is truly dual stack, the applications should have = been updated appropriately to support either address or names. d. Only one DHCPvX provides values. I presume that in this case the = values supplied are appropriate and the other DHCP client should NOT remove the configuration values just because it did not receive that option. Are there other cases? I've excluded multiple administrative domains = since supporting those requires special client considerations anyway. My suggestions on handling these cases: Case (a): This is truly an issue. But, is this significantly different = from the case where a user has configured a value and then the DHCPvX client receives one that is different. Which should be used? So, in my mind = this becomes a policy issue and could be controlled on the host. A host might have a -policy that can be one of "use manually configured", "prefer DHCPv4", "prefer DHCPv6". If "use manually configured", neither DHCP client does anything with the received value. If "prefer DHCPv4", the DHCPv4 client will configure the value when one = is received. The DHCPv6 client can configure the value only if none is set. If "prefer DHCPv6", the DHCPv6 client will configure the value when one = is received. The DHCPv4 client can configure the value only if none is set. Case (b): I assume that merging the DHCPv4 and DHCPv6 lists is proper. A true dual-stack host should have applications that support both = transports. Again, a configuration policy setting may be useful. This would be = allowed to have the following possible values: "prefer DHCPv4" (use only values supplied via DHCPv4), "prefer DHCPv6" (use only values supplied via = DHCPv6), "DHCPv4 first" (place DHCPv4 values first), "DHCPv6 first" (place DHCPv6 values first), "alternate DHCPv4 first" (alternate values, starting with DHCPv4 value), "alternate DHCPv6 first". A DHCP client should maintain a list of the values it configured for the parameter as well as the previously received option value. Whenever the client receives new configuration information, it compares = the received information with the previously received. If there are no = changes, it is done with this parameter. If there are changes, it obtains the current client's configuration and removes the values it added (using the list of values it configured for = the parameter). What remains is either any empty list or a list of values configured through other means. It then adds its values based on the configuration policy as follows: For DHCPv4 client: If "prefer DHCPv4", use only the DHCPv4 received values. If "prefer DHCPv6", if the remaining list is not empty, use it. If it is empty, use the DHCPv4 supplied values. If "DHCPv4 first", use the DHCPv4 received values and then append any remaining values. If "DHCPv6 first", use the remaining values and then append the DHCPv4 received values. If "alternate DHCPv4 first", add values alternating between a DHCPv4 = value and a remaining value. (Once one set is exhausted, append the remaining other set.) If "alternate DHCPv6 first", add values alternating between a remaining value and a DHCPv4 value. (Once one set is exhausted, append the = remaining other set.) For the DHCPv6 client, make the appropriate changes in the above list of actions. If the number of values exceeds the allowed number (or length), truncate = the list to allowed number (or length). The client must (internally) record the list of values it added to the configuration parameter. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 14:25:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08219; Thu, 12 Feb 2004 14: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 1ArMSM-0002rI-Rv; Thu, 12 Feb 2004 14:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMRr-0002n8-CE for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 14:24: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 OAA08180 for ; Thu, 12 Feb 2004 14:24:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMRm-0000wT-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:24:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMQt-0000rK-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:23:32 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1ArMQN-0000lh-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:22:59 -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 i1CJMlGp012212; Thu, 12 Feb 2004 14:23:01 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 12 Feb 2004 14:22:54 -0500 Message-ID: <000701c3f19d$a07186e0$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 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: 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 Would Ted (or ISC) really be liable for this? Wouldn't the USERS or COMMERCIAL DISTRIBUTORS be the ones liable? Sounds like you have much = more practical experience with this sort of stuff, but it just seems to me = that unless Ted (or ISC) claims that the software is patent free, that's something for the users/distributors of the freely available software to contend with? This won't necessarily prevent Ted (or ISC) from being sued (anyone can = be sued) and likely the patent holder would request an injunction to stop distribution of the free software. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Barr Hibbs Sent: Thursday, February 12, 2004 1:08 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt=20 > -----Original Message----- > From: Mark Stapp > Sent: Wednesday, February 11, 2004 12:32 > > where can we go from here? the people who want to stop this draft are > basically saying, "we will stop any drafts from people who've agreed = to > RAND license their IP, and we will stop any drafts as soon as people = other > than the authors agree to RAND license their IP." > ...Mark, you've missed my objection: I was trying to say that while = only the IETF as a whole can address IPR issues (and believe me, NO ONE would want a situation where every single WG or worse, every RFC had different = IPR terms and conditions) the "reasonable and non-discriminatory" terms may = be very difficult or impossible for some vendors to meet. While Ted is not personally the owner of the ISC DHCPD implementation, imagine if he were, and that there were just 3 verified IPR claims = against DHCPD based on patents, trade secrets, copyrights, or other mechanisms. Let's continue by assuming that each "reasonable" license term called = for the payment of $1 for each copy distributed. So, $3 per copy, what's = the big deal? Given that Ted would probably be distributing DHCPD as open-source freeware initially, with anonymous FTP used for = distribution, that distribution model would have to end and copies distributed for, = say, $3.95 each. The extra charge is necessary to pay for the entire e-commerce = application required to register downloads, collect money to pay the license = holders, and to build up a reserve to defend himself when one of his customers illicitly copies the distribution and shares it without license fees = flowing back to the IPR holders. There is no way, in my opinion, to protect = oneself from every possible threat concerning the use of someone else's IPR when license terms include such vague (and potentially meaningless) language = as "reasonable and non-discriminatory." I won't pretend to be an expert on torts, patent and copyright law, or = IPR, but I have been on serveral civil juries deciding breach of contract = suits, nearly all turning on the question of whether one party or the other = truly possessed rights to some property or compensation. In my limited experience, unless the holder of some valuable commodity vigorously and frequently defends their rights, juries (at least in California and New York) seem overwhelmingly to determine that while they may have had = rights "de jure" their inaction defending those rights resulted in a "de facto" abandonment of those rights. So not only does a small vendor have to maintain an e-commerce site and collect monies to pay IPR license holders in my example, the vendor must also vigorously seek out and prosecute those who abuse or ignore the = terms of the vendor's license agreement (instituted to protect the IPR holders among other reasons.) So that $3.95 download and usage license fee is probably too small by an order of magnitude. Imagine if the Free Software Foundation's C/C++ compilers and related = tools were suddenly burdened with license fees, no matter how modest, for a variety of IPR holders. > it doesn't seem reasonable to me to expect that each vendor should = have to > meet different IPR expectations in response to the different = temperatures > of all of the individual working groups. the ietf's consistent overall > expectation allows the standards process to continue in a world where > intellectual property exists, and allows competing commercial vendors = to > contribute. some people in the wg appear to believe that stopping this > draft will allow them to make a statement to the ietf which will > lead it to change its expectations in a way that suits them. as = someone > whose work has become the victim of this energy, I can only ask again = that > the people who object to the ietf's overall expectation address it in = the > IPR wg. > ...you're right, Mark... there should be only one IPR license agreement = for all uses under the guise of IETF, from building commercial or = open-source products to discussing or teaching the technology, and it should meet = nearly impossible criteria: (1) it should be generic enough not to limit an = IPR holder's claims as circumstances and technology changes, (2) it should = be specific enough so that no vendor is left struggling to determine = exactly what uses are permitted (including derivative products) or what are the terms for use, and (3) it needs to offer protection to a vendor if their products are illicitly copied and distributed (effectively holding them harmless against IPR license claims for misuse of products based on or including someone else's protected intellectual property.) I remember the Chicago meeting, when the Relay Agent Information Option nearly lost it's support from the working group because of Motorola's = IPR claims. My memory was a bit faulty, as I had thought that Motorola had agreed to the same IPR limitations as had all other IPR holders whose technologies had been used in RFCs. I'm surprised to learn today that = they were held to a stricter term. I don't think this is a good idea at all. = I do think that we need one solution which addresses the concerns raised = in this message exchange, and as much as I don't want to stomp on your = work, which I'm sure was done innocent of any knowledge of using someone = else's IPR, I fully believe that it is in the best interest of all IETF contributors to resolve the issues Ted raised. Finally, as far as the much-delayed DHCP server MIB is concerned, you = are completely correct: I would be thoroughly disingenuous if I applied a different standard to my contributions than to those of others. I'm not going to withdraw the draft until I've learned more about how IBM's = patent on "Network Alert Message Construction" has actually affected SNMP implementers, but a quick web search turned up several SNMP agent and manager implementations whose licenses make copyright claims, but none = that even acknowledge the IBM patent. _______________________________________________ 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 Feb 12 14:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08504; Thu, 12 Feb 2004 14:29: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 1ArMWD-0003Q5-Fj; Thu, 12 Feb 2004 14: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 1ArMVa-0003KE-05 for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 14:28:22 -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 OAA08444 for ; Thu, 12 Feb 2004 14:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMVV-0001TU-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:28:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMUX-0001IY-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:27:17 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1ArMTb-000169-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:26:19 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 12 Feb 2004 11:26:23 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1CJPnhu001221; Thu, 12 Feb 2004 14:25:49 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGA36880; Thu, 12 Feb 2004 14:25:48 -0500 (EST) Message-Id: <4.3.2.7.2.20040212142354.0203fc58@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Feb 2004 14:25:46 -0500 To: Mark Stapp From: Ralph Droms Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Cc: In-Reply-To: <4.3.2.7.2.20040211141458.02466c20@goblet.cisco.com> References: <06362392-58F6-11D8-A6E8-000A95D9C74C@fugue.com> 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.0 required=5.0 tests=AWL 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: , draft-ietf-ipr-wg-guidelines-05.txt would be a good document to read. It includes specific references to other IPR issues the IETF has dealt with - as well as providing other guidance for the dhc WG issues. - Ralph At 03:32 PM 2/11/2004 -0500, Mark Stapp wrote: >can Ralph or the ADs offer any guidance about whether this kind of storm >has blown up in other groups, and about how we should proceed? > >-- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 14:29:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08536; Thu, 12 Feb 2004 14:29: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 1ArMWE-0003SL-D8; Thu, 12 Feb 2004 14:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMVw-0003O6-UT for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 14:28:45 -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 OAA08476 for ; Thu, 12 Feb 2004 14:28:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMVs-0001Wb-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:28:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMV5-0001Ni-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:27:52 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1ArMU6-0001Eg-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:26:50 -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 i1CJQeGn012932; Thu, 12 Feb 2004 14:26:52 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 12 Feb 2004 14:26:41 -0500 Message-ID: <000c01c3f19e$27aa8800$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 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 BTW, perhaps the stricter terms to say that it is royalty free greatly weaken the case for cross-licensing and hence patent holders are = unlikely to ever state that explicitly, even when they have no intention of charging royalties. - Bernie -----Original Message----- From: Bernie Volz [mailto:volz@metrocast.net]=20 Sent: Thursday, February 12, 2004 2:23 PM To: 'rbhibbs@pacbell.net'; 'dhcwg@ietf.org' Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt=20 Would Ted (or ISC) really be liable for this? Wouldn't the USERS or COMMERCIAL DISTRIBUTORS be the ones liable? Sounds like you have much = more practical experience with this sort of stuff, but it just seems to me = that unless Ted (or ISC) claims that the software is patent free, that's something for the users/distributors of the freely available software to contend with? This won't necessarily prevent Ted (or ISC) from being sued (anyone can = be sued) and likely the patent holder would request an injunction to stop distribution of the free software. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Barr Hibbs Sent: Thursday, February 12, 2004 1:08 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt=20 > -----Original Message----- > From: Mark Stapp > Sent: Wednesday, February 11, 2004 12:32 > > where can we go from here? the people who want to stop this draft are > basically saying, "we will stop any drafts from people who've agreed = to > RAND license their IP, and we will stop any drafts as soon as people = other > than the authors agree to RAND license their IP." > ...Mark, you've missed my objection: I was trying to say that while = only the IETF as a whole can address IPR issues (and believe me, NO ONE would want a situation where every single WG or worse, every RFC had different = IPR terms and conditions) the "reasonable and non-discriminatory" terms may = be very difficult or impossible for some vendors to meet. While Ted is not personally the owner of the ISC DHCPD implementation, imagine if he were, and that there were just 3 verified IPR claims = against DHCPD based on patents, trade secrets, copyrights, or other mechanisms. Let's continue by assuming that each "reasonable" license term called = for the payment of $1 for each copy distributed. So, $3 per copy, what's = the big deal? Given that Ted would probably be distributing DHCPD as open-source freeware initially, with anonymous FTP used for = distribution, that distribution model would have to end and copies distributed for, = say, $3.95 each. The extra charge is necessary to pay for the entire e-commerce = application required to register downloads, collect money to pay the license = holders, and to build up a reserve to defend himself when one of his customers illicitly copies the distribution and shares it without license fees = flowing back to the IPR holders. There is no way, in my opinion, to protect = oneself from every possible threat concerning the use of someone else's IPR when license terms include such vague (and potentially meaningless) language = as "reasonable and non-discriminatory." I won't pretend to be an expert on torts, patent and copyright law, or = IPR, but I have been on serveral civil juries deciding breach of contract = suits, nearly all turning on the question of whether one party or the other = truly possessed rights to some property or compensation. In my limited experience, unless the holder of some valuable commodity vigorously and frequently defends their rights, juries (at least in California and New York) seem overwhelmingly to determine that while they may have had = rights "de jure" their inaction defending those rights resulted in a "de facto" abandonment of those rights. So not only does a small vendor have to maintain an e-commerce site and collect monies to pay IPR license holders in my example, the vendor must also vigorously seek out and prosecute those who abuse or ignore the = terms of the vendor's license agreement (instituted to protect the IPR holders among other reasons.) So that $3.95 download and usage license fee is probably too small by an order of magnitude. Imagine if the Free Software Foundation's C/C++ compilers and related = tools were suddenly burdened with license fees, no matter how modest, for a variety of IPR holders. > it doesn't seem reasonable to me to expect that each vendor should = have to > meet different IPR expectations in response to the different = temperatures > of all of the individual working groups. the ietf's consistent overall > expectation allows the standards process to continue in a world where > intellectual property exists, and allows competing commercial vendors = to > contribute. some people in the wg appear to believe that stopping this > draft will allow them to make a statement to the ietf which will > lead it to change its expectations in a way that suits them. as = someone > whose work has become the victim of this energy, I can only ask again = that > the people who object to the ietf's overall expectation address it in = the > IPR wg. > ...you're right, Mark... there should be only one IPR license agreement = for all uses under the guise of IETF, from building commercial or = open-source products to discussing or teaching the technology, and it should meet = nearly impossible criteria: (1) it should be generic enough not to limit an = IPR holder's claims as circumstances and technology changes, (2) it should = be specific enough so that no vendor is left struggling to determine = exactly what uses are permitted (including derivative products) or what are the terms for use, and (3) it needs to offer protection to a vendor if their products are illicitly copied and distributed (effectively holding them harmless against IPR license claims for misuse of products based on or including someone else's protected intellectual property.) I remember the Chicago meeting, when the Relay Agent Information Option nearly lost it's support from the working group because of Motorola's = IPR claims. My memory was a bit faulty, as I had thought that Motorola had agreed to the same IPR limitations as had all other IPR holders whose technologies had been used in RFCs. I'm surprised to learn today that = they were held to a stricter term. I don't think this is a good idea at all. = I do think that we need one solution which addresses the concerns raised = in this message exchange, and as much as I don't want to stomp on your = work, which I'm sure was done innocent of any knowledge of using someone = else's IPR, I fully believe that it is in the best interest of all IETF contributors to resolve the issues Ted raised. Finally, as far as the much-delayed DHCP server MIB is concerned, you = are completely correct: I would be thoroughly disingenuous if I applied a different standard to my contributions than to those of others. I'm not going to withdraw the draft until I've learned more about how IBM's = patent on "Network Alert Message Construction" has actually affected SNMP implementers, but a quick web search turned up several SNMP agent and manager implementations whose licenses make copyright claims, but none = that even acknowledge the IBM patent. _______________________________________________ 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 Feb 12 14:42:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09410; Thu, 12 Feb 2004 14:42: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 1ArMin-00052E-93; Thu, 12 Feb 2004 14:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMiW-00051O-C5 for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 14:41: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 OAA09336 for ; Thu, 12 Feb 2004 14:41:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMiR-0002w6-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:41:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMhV-0002qR-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:40:41 -0500 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1ArMga-0002kf-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 14:39:44 -0500 Received: from gargoyle.strauf.net (p5089DAA2.dip.t-dialin.net [80.137.218.162]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.10/8.12.9) with ESMTP id i1CJdb4h015272 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 12 Feb 2004 20:39:41 +0100 (CET) Subject: RE: [dhcwg] Dual stack issues From: Christian Strauf To: "'DHCPWG'" In-Reply-To: <000501c3f193$eaa0a930$6401a8c0@BVolz> References: <000501c3f193$eaa0a930$6401a8c0@BVolz> Content-Type: text/plain Organization: JOIN-Team, Uni-Muenster Message-Id: <1076614770.31413.57.camel@gargoyle.strauf.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 12 Feb 2004 20:39:30 +0100 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 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 Bernie! The way I see it, the "prefer DHCPvX" flags pose the real problem: how does a host know when it's running which DHCP client? All implementations I know have the same paradigm: you have an independent DHCPvX client that receives information and puts it into the appropriate places (e.g. configuration files like resolve.conf etc.). How does a DHCPv4 client which read a "prefer DHCPv6" flag for a certain service for instance know that (a) a DHCPv6 client is actually running? (b) the DHCPv6 server is receiving up-to-date information? (c) the latest information is used for the service and there're no "stale values" present? There needs to be some form of coordination between the two DHCP clients (v4/v6) so that values obtained by either protocol are in some way honoured by the other protocol client. There needs to be a way for each client to tell the other client about the internal states it saves for its particular DHC protocol. There are three possible options: (a) Have separate DHCP clients that have a "communications protocol" in an abstract kind of way to exchange information about their state machineries. (b) Have a single client that is "bi-lingual" and speaks DHCPv4 & -v6. (c) Only use a DHCPv6 client to obtain all information. All three of the above options have advantages and disadvantages (the following lists are not complete and just state some major points): (a) Advantages: - DHCP client implementations need minor changes. - Protocol definitions are left untouched. (a) Disadvantages: - Potential problem of inconsistency of the states (how do you handle concurrent changes etc.) - Administrative overhead (MAC, DUIDs and IAIDs need to be handled -- and that is a considerable amount of work for sites with 20k+ hosts) (b) Advantages: - Protocol definitions are left untouched. - You have only one client that knows both state machineries of DHCPv4 & -v6 and therefore consistency is easier to achieve. (b) Disadvantages: - Completely new implementation, old DHCPv4 clients can't simply be modified, a combined new client has to be written. - Same administrative overhead as in (a) (c) Advantages: - DHCPv6 implementations only need slight modifications to include IPv4 options - Consistency is easy because you only have one state machinery (c) Disadvantages: - Client doesn't speak native DHCPv4 anymore - Options need to be "converted" to DHCPv6 options. I think we can assume that (a), (b) and (c) would solve the issues you identified equally well. The question is: which solution is more feasible in practise? I personally doubt that a complete separation of DHCPvX clients on dual-stack hosts will work in all cases, even if a clever admin tries to keep both server configurations as clean as possible. When we wrote the I-Ds, we thought about various solutions which can be kind of boiled down to the above three and (c) was our choice because we think that from our practical experiences, this is the easiest solution to implement which causes less administrative overhead than all others (always keeping large sites in mind). Cheers, Christian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 15:11:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11271; Thu, 12 Feb 2004 15:11: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 1ArNAr-0000OV-1V; Thu, 12 Feb 2004 15: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 1ArNAT-0000F6-8J for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 15:10: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 PAA11108 for ; Thu, 12 Feb 2004 15:10:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNAO-0005o4-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 15:10:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArN9X-0005hS-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 15:09:40 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1ArN8c-0005ae-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 15:08:42 -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 i1CK8f57019624; Thu, 12 Feb 2004 15:08:45 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Christian Strauf'" , "'DHCPWG'" Subject: RE: [dhcwg] Dual stack issues Date: Thu, 12 Feb 2004 15:08:42 -0500 Message-ID: <000d01c3f1a4$033f0c60$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 In-Reply-To: <1076614770.31413.57.camel@gargoyle.strauf.net> 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: 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: >The way I see it, the "prefer DHCPvX" flags pose the real problem: how >does a host know when it's running which DHCP client? I don't see the major problem here. However, my initial process for how = a client updates the configuration was a bit incomplete and a similar procedure to that used for the case (b) in my earlier email needs to be used: - The client maintains what value it set (if it did so in the past). - When the client receives a value from the server, it obtains the = current configuration value. - If the client is the preferred client, it sets the value and records = that it did so. - If the client is not the preferred client, it only sets the value to = the new value if there is no value OR if it last set the value. It records = what it did. (This step can cause a problem in the off chance that the not preferred client set the value initially, the preferred client then set = the same value, and now the non-preferred client receives a new value ... = this can be solved easily enough ...) Ways to solve the communication problems and synchronization are fairly = easy ... both the DHCP clients share a common file. This file is used to synchronize changes and also allows the clients to record who changed = what value. I also see no issue with having a single client that is bilingual. But, = that is not required. Regarding the MAC, client identifier, and DUID, I fully support the work Ted's been doing to adopt the DUID for DHCPv4 clients as the client identifier. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Christian Strauf Sent: Thursday, February 12, 2004 2:40 PM To: 'DHCPWG' Subject: RE: [dhcwg] Dual stack issues Hi Bernie! The way I see it, the "prefer DHCPvX" flags pose the real problem: how does a host know when it's running which DHCP client? All implementations I know have the same paradigm: you have an independent DHCPvX client that receives information and puts it into the appropriate places (e.g. configuration files like resolve.conf etc.). How does a DHCPv4 client which read a "prefer DHCPv6" flag for a certain service for instance know that (a) a DHCPv6 client is actually running? (b) the DHCPv6 server is receiving up-to-date information? (c) the latest information is used for the service and there're no "stale values" present? There needs to be some form of coordination between the two DHCP clients (v4/v6) so that values obtained by either protocol are in some way honoured by the other protocol client. There needs to be a way for each client to tell the other client about the internal states it saves for its particular DHC protocol. There are three possible options: (a) Have separate DHCP clients that have a "communications protocol" in an abstract kind of way to exchange information about their state machineries. (b) Have a single client that is "bi-lingual" and speaks DHCPv4 & -v6. (c) Only use a DHCPv6 client to obtain all information. All three of the above options have advantages and disadvantages (the following lists are not complete and just state some major points): (a) Advantages: - DHCP client implementations need minor changes. - Protocol definitions are left untouched. (a) Disadvantages: - Potential problem of inconsistency of the states (how do you handle concurrent changes etc.) - Administrative overhead (MAC, DUIDs and IAIDs need to be handled -- and that is a considerable amount of work for sites with 20k+ hosts) (b) Advantages: - Protocol definitions are left untouched. - You have only one client that knows both state machineries of DHCPv4 & -v6 and therefore consistency is easier to achieve. (b) Disadvantages: - Completely new implementation, old DHCPv4 clients can't simply be modified, a combined new client has to be written. - Same administrative overhead as in (a) (c) Advantages: - DHCPv6 implementations only need slight modifications to include IPv4 options - Consistency is easy because you only have one state machinery (c) Disadvantages: - Client doesn't speak native DHCPv4 anymore - Options need to be "converted" to DHCPv6 options. I think we can assume that (a), (b) and (c) would solve the issues you identified equally well. The question is: which solution is more feasible in practise? I personally doubt that a complete separation of DHCPvX clients on dual-stack hosts will work in all cases, even if a clever admin tries to keep both server configurations as clean as possible. When we wrote the I-Ds, we thought about various solutions which can be kind of boiled down to the above three and (c) was our choice because we think that from our practical experiences, this is the easiest solution to implement which causes less administrative overhead than all others (always keeping large sites in mind). Cheers, Christian _______________________________________________ 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 Feb 12 15:57:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14924; Thu, 12 Feb 2004 15:57: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 1ArNtM-0004uy-71; Thu, 12 Feb 2004 15:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNso-0004qA-OQ for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 15:56:26 -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 PAA14834 for ; Thu, 12 Feb 2004 15:56:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNsl-00032V-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 15:56:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNrm-0002vZ-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 15:55:23 -0500 Received: from smtp101.mail.sc5.yahoo.com ([216.136.174.139]) by ietf-mx with smtp (Exim 4.12) id 1ArNqo-0002om-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 15:54:22 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp101.mail.sc5.yahoo.com with SMTP; 12 Feb 2004 20:54:23 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 12 Feb 2004 12:59:04 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000001c3f115$5461f920$6401a8c0@BVolz> Importance: 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 > -----Original Message----- > From: Bernie Volz > Sent: Wednesday, February 11, 2004 19:07 > > Another point is that these IPR statements don't exactly tell you what the > IP is -- and patent lawyers would tell any patent holder that saying any > more is a very bad idea. Patents make multiple claims where the I-D work > may be just one part. > ...William Shakespeare: "First, kill all the lawyers." > While I am with Ted and Barr that I would prefer that there were no > patents especially on pretty basic stuff.... > ...I definitely regret my choice of words.... My preference is that the requirements for an IPR claim for technology used in an RFC be clear and explicit, both in terms of identifying the claimed IP and in specifying the license terms and conditions. > So, as long as the IPR statements are aligned with the general IETF > guidelines, I don't think we should block forward progress. > ...while PacketFront's new IPR statement is compatible with IETF guidelines, unless we understand precisely what part of Mark's draft is claimed by PacketFront, I don't think we should advance it: are they claiming sub-options? subscriber identifier? client identifier? I just don't like such huge unknowns, especially for something that seems so straightforward. > I'd also prefer that IPR warnings are placed on I-Ds/RFCs. That way, we at > least know that the work is likely to be encumbered. > ...that is an excellent suggestion --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 16:11:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16203; Thu, 12 Feb 2004 16:11: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 1ArO6w-0006gh-5D; Thu, 12 Feb 2004 16: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 1ArO61-0006du-Dh for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 16:10:05 -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 QAA15944 for ; Thu, 12 Feb 2004 16:10:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO5x-0004ov-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 16:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO4t-0004eD-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 16:08:55 -0500 Received: from smtp105.mail.sc5.yahoo.com ([66.163.169.225]) by ietf-mx with smtp (Exim 4.12) id 1ArO49-0004Uk-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 16:08:10 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp105.mail.sc5.yahoo.com with SMTP; 12 Feb 2004 21:08:11 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 12 Feb 2004 13:12:51 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000701c3f19d$a07186e0$6401a8c0@BVolz> Importance: 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 > -----Original Message----- > From: Bernie Volz > Sent: Thursday, February 12, 2004 11:23 > > Would Ted (or ISC) really be liable for this? Wouldn't the USERS or > COMMERCIAL DISTRIBUTORS be the ones liable? > ...of course I can't speak for all holders of IPR and their attorneys, but one generally goes after either the most obvious target or the targets with the deepest pockets in a lawsuit. Going after Ted for an alleged infringement in DHCPD would effectively halt all development and author support of the product, which might be the intent of the legislation. The ISC is actually the owner of DHCPD, so attacking them could halt original distribution and development. A few large wins over users such as SBC would also kill off DHCPD pretty effectively, as would a win against FreshMeat for their RPM packages. > ... it just seems to me that unless Ted (or ISC) claims that the software > is patent free, that's something for the users/distributors of the freely > available software to contend with? > ...ignorance is no defense in most civil jurisdictions, and while claiming something is unencumbered when it, in fact, is would be considered misrepresentation or fraud, being silent doesn't shield anyone either > This won't necessarily prevent Ted (or ISC) from being sued (anyone can be > sued) and likely the patent holder would request an injunction to stop > distribution of the free software. > we'd all be much the poorer for it if it were to occur --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 17:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20149; Thu, 12 Feb 2004 17: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 1ArPMM-0005PC-Ua; Thu, 12 Feb 2004 17: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 1ArPLw-0005Ny-7l for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 17:30: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 RAA20110 for ; Thu, 12 Feb 2004 17:30:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPLr-00051A-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 17:30:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPKw-0004vp-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 17:29:34 -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 1ArPKe-0004qB-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 17:29:16 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1CMSluA021521 for ; Thu, 12 Feb 2004 14:28:47 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGA54930; Thu, 12 Feb 2004 17:28:46 -0500 (EST) Message-Id: <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Feb 2004 17:28:30 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] draft-ietf-dhc-agentopt-radius-04.txt submitted for publication 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: , draft-ietf-dhc-agentopt-radius-04.txt has been revised to address comments from an IESG-sponsored reviewer prior to IETF last call, and has been submitted for publication at www.ietf.org (it should be announced sooon). It's now ready for reconsideration by the IESG. Because this document has been part of the recent discussion of IPR issues on the dhcwg mailing list, I want to bring the document's status to the attention of the WG. This document contains a Terms of Use section with a pointer to an IPR statement, http://www.ietf.org/ietf/IPR/CISCO-8021X.txt, in accordance with the guidelines in RFC 2026. Are there any objections to returning the document to the IESG for reconsideration? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From agdpress_release@hotmail.com Thu Feb 12 19:08:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26110 for ; Thu, 12 Feb 2004 19:08:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQsw-0007Wo-00 for dhc-archive@ietf.org; Thu, 12 Feb 2004 19:08:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQqZ-00072B-00 for dhc-archive@ietf.org; Thu, 12 Feb 2004 19:06:21 -0500 Received: from [210.23.200.62] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1ArQoT-0006cJ-00; Thu, 12 Feb 2004 19:04:10 -0500 From: "Atualidade Brasileira . yls" To: dccp-request@ietf.org Subject: Lindenberg e a "demonização" da livre iniciativa ref.: psv 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: Thu, 12 Feb 2004 19:04:10 -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=13.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS 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.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 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 * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 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

(usp) Lindenberg:EnEspañol - English:LinkToFreeTranslator

Série Temas Patrulhados (3)

Lindenberg e a "demonização" da livre iniciativa

"Muito embora capitalismo, globalização, neoliberalismo, privatizações, propriedade privada etc. não se identifiquem necessáriamente, eles são vistos pelos herdeiros das idéias marxistas como as quatro bestas do Apocalipse"

Viés

* 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" inspiradas na teologia da libertação e nos Fórums Sociais: os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

"As quatro bestas do Apocalipse"?

* Em artigo "Capitalismo, globalização, neoliberalismo, privatizações", da Série Temas Patrulhados, Lindenberg constata que muito embora capitalismo, globalização, neoliberalismo, privatizações, propriedade privada etc. não se identifiquem necessáriamente, têm, no entanto, um denominador comum: são vistos pelos progressistas e pelos herdeiros das idéias marxistas como "as quatro bestas do Apocalipse".

Com efeito, essas pessoas, sem terem condições de apregoar as benesses do socialismo - por causa dos contrastes gritantes das economias livres versus economias estatizadas, e do fracasso estrondoso destas ultimas - denunciam de maneira generalizada as políticas de austeridade, as multinacionais e as privatizações dos serviços públicos, como sendo as responsáveis pelo crescimento dos bolsões de miséria, estagnação econômica e concentração da renda.

Bom senso

* Em seu artigo "Capitalismo, globalização, neoliberalismo, privatizações", Lindenberg usa o bom senso e uma linguagem acessível para recolocar as idéias em sua justa ordem. Seguem alguns temas abordados no artigo, que o leitor receberá gratuitamente por e-mail, na íntegra, simplesmente clicando em: EsteArtigoGratuitamente(3) .

- Os ideais da livre empresa e da economia de mercado, e o direito de propriedade segundo os ensinamentos tradicionais da Igreja.

- A ordem socioeconômica cristã personalizada e orgânica, isto é, uma ordem na qual a preeminência deve ser dada às famílias e às sociedades intermediárias, e não ao Estado.

- As campanhas de descrédito contra a propriedade privada.

- A verdade sobre o chamado "capitalismo selvagem".

. Em que consiste o capitalismo popular ou democrático.

. A viga mestre do progresso econômico cristão.

. O contraste entre os padrões de vida e de assistência social dos países livres, e dos países com economias estatizantes.

Links para receber e-Book e artigos gratuitos

Lindenberg:e-BookGratuito (em formato Word, com 11 artigos de Lindenberg)

EsteArtigoCompletoGratuitamente(No.3)

Lindenberg:LivroIntroduçãoGratuita (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, incluindo sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:Opinião/Sugestão

Lindenberg:GratuitamenteEsteArtigo(3)

Link em espanhol

Lindenberg:e-BookGratuitoEsp (em formato Word, com 11 artigos de Lindenberg, em Espanhol)

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil e em Portugal)

Lindenberg:Subscrever (para receber, gratuitamente, os próximos artigos)

ConstruNews:Remover (para ser retirado imediatamente de nosso Address Book).

 

A difusão deste artigo, com a finalidade estritamente cívica e cultural de promover um debate respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews.

 

 

From dhcwg-admin@ietf.org Thu Feb 12 19:13:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27263; Thu, 12 Feb 2004 19:13: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 1ArQx4-0004YJ-Dr; Thu, 12 Feb 2004 19:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQwX-0004Ua-UE for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 19:12: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 TAA27053 for ; Thu, 12 Feb 2004 19:12:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQwU-0000a4-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:12:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQuX-00006w-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:10:26 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ArQsP-0007Ob-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:08:13 -0500 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id C408C1B5CFA; Thu, 12 Feb 2004 17:56:32 -0600 (CST) In-Reply-To: <000701c3f19d$a07186e0$6401a8c0@BVolz> References: <000701c3f19d$a07186e0$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "" From: Ted Lemon Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 12 Feb 2004 16:16:51 -0500 To: "Bernie Volz" X-Mailer: Apple Mail (2.612) 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 On Feb 12, 2004, at 2:22 PM, Bernie Volz wrote: > Would Ted (or ISC) really be liable for this? Wouldn't the USERS or > COMMERCIAL DISTRIBUTORS be the ones liable? Sounds like you have much > more Actually, they could hold me, ISC *and* the end-user all separately liable. No, I'm not making this up - it's been tested recently. If you search the Your Rights Online archive on /., you should be able to find a reference - I think a case was decided in the past month or two that turned on the IP owner's right to sue either the seller of the software or the user of the software for infringement. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 19:13:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27264; Thu, 12 Feb 2004 19:13: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 1ArQx3-0004YB-Vo; Thu, 12 Feb 2004 19:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQwO-0004UU-FP for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 19:12:22 -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 TAA27049 for ; Thu, 12 Feb 2004 19:12:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQwK-0000YN-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:12:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQuV-00006V-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:10:24 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ArQsO-0007O0-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:08:12 -0500 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 2B4991B3D73; Thu, 12 Feb 2004 17:56:23 -0600 (CST) In-Reply-To: <20040212134801.GQ32618@sverresborg.uninett.no> References: <402B7FB1.9060504@india.hp.com> <20040212134801.GQ32618@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Vijayabhaskar A K , DHCPWG From: Ted Lemon Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] Date: Thu, 12 Feb 2004 16:10:29 -0500 To: Stig Venaas X-Mailer: Apple Mail (2.612) 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 we're going down a rathole here. You may think it's easier to have one DHCPv6 server and no DHCPv4 server in a dual-stack environment, and that may even be true, but we are discussing making substantial and painful changes to the protocol to accomodate your preference. It seems to me that it would be easier to just have a DHCP server that supports both DHCPv4 and DHCPv6 from the same configuration. I can easily imagine how to implement such a thing, and I think the difficulty of administering it would be about the same as the difficulty of administering a DHCPv4-only server. This requires no new protocol nastiness, and provides a nice new product space in which the several DHCP server vendors on this mailing list can compete. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 20:03:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27262; Thu, 12 Feb 2004 19:13: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 1ArQx4-0004YS-SI; Thu, 12 Feb 2004 19:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQwZ-0004Uk-7S for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 19:12: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 TAA27059 for ; Thu, 12 Feb 2004 19:12:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQwV-0000bx-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:12:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQuY-00007W-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:10:27 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ArQsR-0007Oy-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 19:08:15 -0500 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id BCA821B2143; Thu, 12 Feb 2004 17:56:40 -0600 (CST) In-Reply-To: <000c01c3f19e$27aa8800$6401a8c0@BVolz> References: <000c01c3f19e$27aa8800$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77DE601E-5DA5-11D8-B5DC-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "" From: Ted Lemon Subject: Re: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 12 Feb 2004 16:50:26 -0500 To: "Bernie Volz" X-Mailer: Apple Mail (2.612) 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 On Feb 12, 2004, at 2:26 PM, Bernie Volz wrote: > BTW, perhaps the stricter terms to say that it is royalty free greatly > weaken the case for cross-licensing and hence patent holders are > unlikely to > ever state that explicitly, even when they have no intention of > charging > royalties. That seems unlikely. Furthermore, it is immaterial. I don't think it's a good idea for the IETF to release standards that are encumbered in this way, regardless of what the implications are for the patent holder if they grant zero-royalty rights. If there's a strong reason to do it, then maybe we have to do it. In this case, there is no clear benefit to doing it, as far as I can tell. It's clearly within the purview of each working group to say "we won't use this thing because of IPR restrictions we don't like." _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 20:30:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00257; Thu, 12 Feb 2004 20:30: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 1ArS9Z-00012P-Ow; Thu, 12 Feb 2004 20:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArS9I-00011U-3g for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 20:29: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 UAA00225 for ; Thu, 12 Feb 2004 20:29:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArS9D-0000Cc-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 20:29:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArS8B-000084-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 20:28:35 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ArS7g-000038-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 20:28:04 -0500 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 68BBD1B981A; Thu, 12 Feb 2004 19:16:28 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> References: <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) 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] draft-ietf-dhc-agentopt-radius-04.txt submitted for publication Date: Thu, 12 Feb 2004 20:27:44 -0500 To: Ralph Droms X-Mailer: Apple Mail (2.612) 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 On Feb 12, 2004, at 5:28 PM, Ralph Droms wrote: > Are there any objections to returning the document to the IESG for > reconsideration? It sounds like you folks have some patent applications pending, and can't talk about exactly what's covered. I think it might be best if the WG waited until the patents were made public before making a decision on this. It's possible that the patents don't actually apply to the option, but just to what you're doing with 802.1x, and then there'd be no need for people to worry about infringing if they implemented this draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 21:10:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02386; Thu, 12 Feb 2004 21:10: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 1ArSmH-0004HV-8V; Thu, 12 Feb 2004 21:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSlt-0004GN-PN for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 21:09: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 VAA02373 for ; Thu, 12 Feb 2004 21:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArSlp-0004kz-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:09:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArSks-0004eu-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:08:34 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ArSju-0004Uu-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:07:34 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1D274cw016986 for ; Thu, 12 Feb 2004 18:07:04 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-161.cisco.com [10.86.240.161]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGA68260; Thu, 12 Feb 2004 21:06:59 -0500 (EST) Message-Id: <4.3.2.7.2.20040212210425.02958e08@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Feb 2004 21:06:55 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-agentopt-radius-04.txt submitted for publication In-Reply-To: References: <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> 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.0 required=5.0 tests=AWL 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: , I'll find out when we can talk about what's covered. However, hypothetically speaking, if we can't talk about what's covered until, for example, a patent is actually granted, you might have to ask me to come out of retirement to explain it. - Ralph At 08:27 PM 2/12/2004 -0500, Ted Lemon wrote: >On Feb 12, 2004, at 5:28 PM, Ralph Droms wrote: >>Are there any objections to returning the document to the IESG for >>reconsideration? > >It sounds like you folks have some patent applications pending, and can't >talk about exactly what's covered. I think it might be best if the WG >waited until the patents were made public before making a decision on >this. It's possible that the patents don't actually apply to the option, >but just to what you're doing with 802.1x, and then there'd be no need for >people to worry about infringing if they implemented this draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 12 21:34:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03235; Thu, 12 Feb 2004 21:34: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 1ArT9U-0005bH-TL; Thu, 12 Feb 2004 21:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArT9E-0005Z9-TW for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 21:33: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 VAA03209 for ; Thu, 12 Feb 2004 21:33:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArT9A-0006wN-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:33:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArT87-0006rU-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:32:36 -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 1ArT7p-0006n8-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:32:17 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Feb 2004 18:39:41 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1D2VluA007960 for ; Thu, 12 Feb 2004 18:31:48 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-161.cisco.com [10.86.240.161]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGA69471; Thu, 12 Feb 2004 21:31:47 -0500 (EST) Message-Id: <4.3.2.7.2.20040212212854.02961620@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Feb 2004 21:31:44 -0500 To: From: Ralph Droms Subject: RE: [dhcwg] IPR statement related to draft-ietf-dhc-subscriber-id-X.txt In-Reply-To: <4.3.2.7.2.20040212142354.0203fc58@flask.cisco.com> References: <4.3.2.7.2.20040211141458.02466c20@goblet.cisco.com> <06362392-58F6-11D8-A6E8-000A95D9C74C@fugue.com> 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.0 required=5.0 tests=AWL 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: , draft-ietf-ipr-wg-guidelines-05.txt and two other, related, documents have just been published (today, coincidentally) as RFCs: RFC 3667, "IETF Rights in Contributions" RFC 3668, "Intellectual Property Rights in IETF Technology" RFC 3669, "Guidelines for Working Groups on Intellectual Property Issues" - Ralph At 02:25 PM 2/12/2004 -0500, Ralph Droms wrote: >draft-ietf-ipr-wg-guidelines-05.txt would be a good document to read. It >includes specific references to other IPR issues the IETF has dealt with - >as well as providing other guidance for the dhc WG issues. > >- Ralph > >At 03:32 PM 2/11/2004 -0500, Mark Stapp wrote: > >>can Ralph or the ADs offer any guidance about whether this kind of storm >>has blown up in other groups, and about how we should proceed? >> >>-- Mark > > >_______________________________________________ >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 Feb 12 21:50:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04065; Thu, 12 Feb 2004 21: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 1ArTP0-0006Xz-UQ; Thu, 12 Feb 2004 21:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTOf-0006XJ-Ie for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 21:49: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 VAA04059 for ; Thu, 12 Feb 2004 21:49:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTOa-0000de-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:49:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTNg-0000ZA-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:48:41 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1ArTNT-0000UD-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 21:48:27 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2004 18:45:44 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1D2lwhu014076; Thu, 12 Feb 2004 21:47:58 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-161.cisco.com [10.86.240.161]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGA70107; Thu, 12 Feb 2004 21:46:45 -0500 (EST) Message-Id: <4.3.2.7.2.20040212214139.0293e500@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Feb 2004 21:46:41 -0500 To: Ted Lemon From: Ralph Droms Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] Cc: DHCPWG In-Reply-To: References: <20040212134801.GQ32618@sverresborg.uninett.no> <402B7FB1.9060504@india.hp.com> <20040212134801.GQ32618@sverresborg.uninett.no> 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.0 required=5.0 tests=AWL 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: , Ted - I was talking about the same idea with some of my colleagues here at Cisco earlier today. Seems like it would be relatively straightforward to write a configuration manager that would accept a single configuration specification from the service manager and parcel out the right config pieces to the DHCPv4 and DHCPv6 servers. In this case, maintaining coordinated configurations in two servers is an interface issue, not a protocol issue. - Ralph At 04:10 PM 2/12/2004 -0500, Ted Lemon wrote: >I think we're going down a rathole here. You may think it's easier to >have one DHCPv6 server and no DHCPv4 server in a dual-stack environment, >and that may even be true, but we are discussing making substantial and >painful changes to the protocol to accomodate your preference. > >It seems to me that it would be easier to just have a DHCP server that >supports both DHCPv4 and DHCPv6 from the same configuration. I can >easily imagine how to implement such a thing, and I think the difficulty >of administering it would be about the same as the difficulty of >administering a DHCPv4-only server. This requires no new protocol >nastiness, and provides a nice new product space in which the several DHCP >server vendors on this mailing list can compete. :') > > >_______________________________________________ >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 Feb 12 22:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04906; Thu, 12 Feb 2004 22:11: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 1ArTjK-0008AS-9H; Thu, 12 Feb 2004 22: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 1ArTiv-00089o-MZ for dhcwg@optimus.ietf.org; Thu, 12 Feb 2004 22:10: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 WAA04895 for ; Thu, 12 Feb 2004 22:10:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTip-0002ZU-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 22:10:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArThr-0002VP-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 22:09:31 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ArTgt-0002Pe-00 for dhcwg@ietf.org; Thu, 12 Feb 2004 22:08:31 -0500 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id BD2121B9986; Thu, 12 Feb 2004 20:56:59 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040212210425.02958e08@flask.cisco.com> References: <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> <4.3.2.7.2.20040212210425.02958e08@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) 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] draft-ietf-dhc-agentopt-radius-04.txt submitted for publication Date: Thu, 12 Feb 2004 22:08:15 -0500 To: Ralph Droms X-Mailer: Apple Mail (2.612) 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 On Feb 12, 2004, at 9:06 PM, Ralph Droms wrote: > However, hypothetically speaking, if we can't talk about what's covered > until, for example, a patent is actually granted, you might have to ask > me to come out of retirement to explain it. From my side, I'm willing to wait. This is functionality I don't think is particularly useful, although it's certainly cool, and it requires a conforming DHCP implementation to be subject to the possibility of having to pay royalties (although I know Cisco's current practice is not to charge royalties in this case, it's still a potential risk down the road). I would be curious to know what the position of other wg members is on this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 03:24:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27908; Fri, 13 Feb 2004 03:24:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYbF-0004Cd-8j; Fri, 13 Feb 2004 03: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 1ArYb6-0004Bb-OP for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 03:22: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 DAA27888 for ; Fri, 13 Feb 2004 03:22:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYay-0006aF-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 03:22:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYa2-0006WN-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 03:21:47 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1ArYZR-0006Ns-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 03:21:10 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1D8Kb807397; Fri, 13 Feb 2004 15:20:38 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1D8JN004537; Fri, 13 Feb 2004 15:19:24 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: Ted Lemon , DHCPWG Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] In-Reply-To: <4.3.2.7.2.20040212214139.0293e500@flask.cisco.com> References: <4.3.2.7.2.20040212214139.0293e500@flask.cisco.com> <20040212134801.GQ32618@sverresborg.uninett.no> <402B7FB1.9060504@india.hp.com> <20040212134801.GQ32618@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 2004 15:19:23 +0700 Message-ID: <11385.1076660363@munnari.OZ.AU> 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Thu, 12 Feb 2004 21:46:41 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20040212214139.0293e500@flask.cisco.com> | Ted - I was talking about the same idea with some of my colleagues here at | Cisco earlier today. Seems like it would be relatively straightforward to | write a configuration manager that would accept a single configuration | specification from the service manager and parcel out the right config | pieces to the DHCPv4 and DHCPv6 servers. Damn, Ted got his message in first - I was going to say just the same thing. Whether there is a DHCPv4 server, and a DHCPv6 server, with separate configurations, a single configuration split by a tool (of some kind) and fed to separate servers, or one server, that implements both the DHCPv4 and DHCPv6 protocols, and takes a single configuration, sending whatever information is appropriate in each offer (just as a single protocol server does) is really all irrelevant to the protocol specifications. People worried about having to manage two different servers just need to acquire a single server (or a single management interface). There's nothing difficult about this. Others who want to manage their v4 and v6 stacks entirely separately can use independent servers and configurations. On the other hand, is the DHCPv6 protocol were altered (or simply specified) to supply v4 configuration information (by sending around v4 compatible v6 addresses), then consider what happens when your typical client first does its normal v4 configuration, and talks to the v4 server, and gets v4 information that way, and then the v6 stack talks to its v6 dhcp server, gets its v6 configuration information (fine) but also gets a bunch of v4 configuration info, and proceeds to alter the configuration that was already made for the v4 stack. That possibility isn't even worth contemplating. Keep v4 addresses completely out of the DHCPv6 protocol. The other info, that can be delivered by both servers (names, etc) which is IP version neutral just gets delivered by both - in exactly the same way as it gets delivered to each of N interfaces. It is a server management issue to make all of that remain consistent so the client doesn't need to try and guess which interface's (or which stack's) value is the correct one to use. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 06:26:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04991; Fri, 13 Feb 2004 06:26: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 1ArbSM-0002ew-22; Fri, 13 Feb 2004 06:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWWJ-00036m-OA for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 01:09: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 BAA10279 for ; Fri, 13 Feb 2004 01:09:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWWC-0002uM-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 01:09:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWVG-0002q4-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 01:08:43 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1ArWUP-0002lv-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 01:07:50 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7009215210; Fri, 13 Feb 2004 15:07:50 +0900 (JST) Date: Fri, 13 Feb 2004 15:07:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vijayabhaskar A K Cc: Stig Venaas , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt In-Reply-To: <402A34D0.1060800@india.hp.com> References: <2427813621.1076316018@localhost> <20040211061541.GB29599@sverresborg.uninett.no> <402A0224.80507@india.hp.com> <20040211103756.GI29785@sverresborg.uninett.no> <402A34D0.1060800@india.hp.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-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 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'm feeling this particular discussion is not appropriate for this list. So, this will be my last message on this topic) >>>>> On Wed, 11 Feb 2004 19:27:36 +0530, >>>>> Vijayabhaskar A K said: > draft-itojun-v6ops-v4mapped-harmful says: > o IPv6 nodes SHOULD NOT generate packets that contain IPv4-mapped > addresses in any field. (As a particular exception, it MAY be > acceptable for fields referring to third-party nodes to contain > IPv4-mapped addresses. Implementors must ensure that, where this is > allowed, it is done with great care.) > I guess, our situation perfectly falls in this.. Perhaps (I guess you mean the "exception" by "this"). But to be sure, we'll have to make several points clearer (IMO): - whether this document is adopted by some wg to be published (if not, we won't have to worry about this in the first place) - while the document say "SHOULD NOT" for any field of an IPv6 packet (which I believe includes the upper layer header and its payload), the document only talks about the problematic cases where mapped addresses are used in the source/destination fields of an IPv6 header. If these fields are only place that can cause a problem, we'll be able to eliminate the "SHOULD NOT" completely. - if we have enough reason to keep the "SHOULD NOT", then the above statement should be clearer, including what exactly "any field" means or how we can ensure "it is done with great care". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 09:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11100; Fri, 13 Feb 2004 09:43: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 1AreX0-0001Iy-Eb; Fri, 13 Feb 2004 09:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreW4-0001FI-N5 for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 09:42:05 -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 JAA11033 for ; Fri, 13 Feb 2004 09:42:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AreW2-0005qG-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:42:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AreV9-0005mF-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:41:08 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AreUT-0005e2-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:40:25 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i1DGIew4030643 for ; Fri, 13 Feb 2004 08:18:40 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Fri, 13 Feb 2004 05:59:30 -0800 Message-Id: <5.1.0.14.2.20040213082935.0426d120@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 13 Feb 2004 08:54:07 -0500 To: Ted Lemon From: Margaret Wasserman Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] Cc: Stig Venaas , Vijayabhaskar A K , DHCPWG , Harald Tveit Alvestrand In-Reply-To: References: <20040212134801.GQ32618@sverresborg.uninett.no> <402B7FB1.9060504@india.hp.com> <20040212134801.GQ32618@sverresborg.uninett.no> 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.0 required=5.0 tests=AWL 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: , At 04:10 PM 2/12/2004 -0500, Ted Lemon wrote: >It seems to me that it would be easier to just have a DHCP server that >supports both DHCPv4 and DHCPv6 from the same configuration. I can >easily imagine how to implement such a thing, and I think the difficulty >of administering it would be about the same as the difficulty of >administering a DHCPv4-only server. This requires no new protocol >nastiness, and provides a nice new product space in which the several DHCP >server vendors on this mailing list can compete. :') And how would the client put it back together? I really feel like we are having a classic failure to communicate... So, let me try an example. Let's suppose that I have a set of servers that provide a single service that is accessible via IPv4 of IPv6 transports. How do I configure all of the nodes in a network (that might include IPv4-only, dual-stack or, perhaps in the future, IPv6-only nodes) to reach that service? To be more specific: Let's say that I have 4 DNS Servers in my site. Let's say that I am only starting to roll out IPv6, so 2 of my DNS servers are dual-stack (providing service over IPv4 and IPv6 transports) and two of them are only available via the IPv4 transport. My servers could have the following IP addresses: Server1: IPv6-Addr1 IPv4-Addr1 Server2: IPv4-Addr2 Server3: IPv6-Addr3 IPv4-Addr3 Server4: IPv4-Addr4 Let's also assume that I have two nodes somewhere on my network, Node1 and Node2. Node1 is an IPv4-only node, and Node2 is a dual- stack (IPv4 and IPv6 node). Both nodes are configured to get their IPv4 addresses using DHCPv4, and Node2 uses IPv6 autoconfiguration to generate IPv6 addresses. Let's also assume that the DNS search list for each of these nodes should be in the order I have listed the servers above (Server1, Server2, Server3, Server4), and that I want the dual-stack node to use the IPv6 addresses for Server1 and Server3. So this is what I want to configure in each node's DNS server list: Node1: IPv4-Addr1, IPv4-Addr2, IPv4-Addr3, IPv4-Addr4 Node2: IPv6-Addr1, IPv4-Addr2, IPv6-Addr3, IPv4-Addr4 So, how do I do that? Well, I have to configure my DHCPv4 server to return all four of the IPv4 addresses, right? And, I guess you'd have me configure my DHCPv6 server to return only the two IPv6 addresses? So, Node1 will be configured correctly, but Node 2 will get _two_ lists of DNS server addresses (the IPv4 ones and the IPv6 ones). Which ones will it try first? There doesn't seem to be any priority or meta-information associated with any DHCP options that would allow Node2 to decide how to order the six entries it receives. There also doesn't seem to be a way for Node2 to know that two of the entries in the IPv4 table point to the same DNS servers as the two IPv6 entries. There seems to be some desire to sweep these decisions under the rug of "client implementation", but I can't see that our DHCPv6 options, as currently defined, are providing enough information for the client to make a reasonable choice. Margaret _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 10:00:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11877; Fri, 13 Feb 2004 10:00: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 1ArenT-0002gI-AY; Fri, 13 Feb 2004 10:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AremW-0002cC-Ep for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 09: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 JAA11829 for ; Fri, 13 Feb 2004 09:59:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AremU-0007Mm-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:59:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arela-0007Ik-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:58:06 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Arekq-00079l-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:57:20 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 13 Feb 2004 06:57:30 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1DEumhu003187 for ; Fri, 13 Feb 2004 09:56:48 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGA92994; Fri, 13 Feb 2004 09:56:47 -0500 (EST) Message-Id: <4.3.2.7.2.20040213094750.02a77558@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Feb 2004 09:56:46 -0500 To: DHCPWG From: Ralph Droms Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] In-Reply-To: <5.1.0.14.2.20040213082935.0426d120@ms101.mail1.com> References: <20040212134801.GQ32618@sverresborg.uninett.no> <402B7FB1.9060504@india.hp.com> <20040212134801.GQ32618@sverresborg.uninett.no> 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.0 required=5.0 tests=AWL 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: , I think we're just talking about different sides of the problem - the server side and the client side. And we have to solve both sides of the problem. Ted, kre and I are commenting on the server side - from the network admin's point of view, a requirement for both DHCPv4 and DHCPv6 messages on the wire does not add complexity to the admin's job. An appropriate single administration interface, for either a single server sending both DHCPv4 and DHCPv6 or two separate servers, can coordinate the DHCPv4 and DHCPv6 services. From the client side, we have to define how the client puts things back together. But this problem may be simplified if we assume that the DHCPv4 and DHCPv6 services, presumably run in the same administrative domain, can be managed to avoid conflicting configuration information. - Ralph At 08:54 AM 2/13/2004 -0500, Margaret Wasserman wrote: >At 04:10 PM 2/12/2004 -0500, Ted Lemon wrote: >>It seems to me that it would be easier to just have a DHCP server that >>supports both DHCPv4 and DHCPv6 from the same configuration. I can >>easily imagine how to implement such a thing, and I think the difficulty >>of administering it would be about the same as the difficulty of >>administering a DHCPv4-only server. This requires no new protocol >>nastiness, and provides a nice new product space in which the several >>DHCP server vendors on this mailing list can compete. :') > >And how would the client put it back together? > >I really feel like we are having a classic failure to communicate... >So, let me try an example. > >Let's suppose that I have a set of servers that provide a single >service that is accessible via IPv4 of IPv6 transports. How do I >configure all of the nodes in a network (that might include IPv4-only, >dual-stack or, perhaps in the future, IPv6-only nodes) to reach that >service? > >To be more specific: > >Let's say that I have 4 DNS Servers in my site. Let's say that I am >only starting to roll out IPv6, so 2 of my DNS servers are dual-stack >(providing service over IPv4 and IPv6 transports) and two of them are >only available via the IPv4 transport. My servers could have the >following IP addresses: > >Server1: IPv6-Addr1 > IPv4-Addr1 > >Server2: IPv4-Addr2 > >Server3: IPv6-Addr3 > IPv4-Addr3 > >Server4: IPv4-Addr4 > >Let's also assume that I have two nodes somewhere on my network, >Node1 and Node2. Node1 is an IPv4-only node, and Node2 is a dual- >stack (IPv4 and IPv6 node). Both nodes are configured to get their >IPv4 addresses using DHCPv4, and Node2 uses IPv6 autoconfiguration >to generate IPv6 addresses. > >Let's also assume that the DNS search list for each of these nodes >should be in the order I have listed the servers above (Server1, >Server2, Server3, Server4), and that I want the dual-stack node >to use the IPv6 addresses for Server1 and Server3. So this >is what I want to configure in each node's DNS server list: > >Node1: IPv4-Addr1, IPv4-Addr2, IPv4-Addr3, IPv4-Addr4 > >Node2: IPv6-Addr1, IPv4-Addr2, IPv6-Addr3, IPv4-Addr4 > >So, how do I do that? > >Well, I have to configure my DHCPv4 server to return all four >of the IPv4 addresses, right? > >And, I guess you'd have me configure my DHCPv6 server to return >only the two IPv6 addresses? > >So, Node1 will be configured correctly, but Node 2 will get >_two_ lists of DNS server addresses (the IPv4 ones and the IPv6 >ones). Which ones will it try first? There doesn't seem to be >any priority or meta-information associated with any DHCP options >that would allow Node2 to decide how to order the six entries >it receives. There also doesn't seem to be a way for Node2 >to know that two of the entries in the IPv4 table point to the >same DNS servers as the two IPv6 entries. > >There seems to be some desire to sweep these decisions under >the rug of "client implementation", but I can't see that our >DHCPv6 options, as currently defined, are providing enough >information for the client to make a reasonable choice. > >Margaret > > > > > > > >_______________________________________________ >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 Feb 13 10:11:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13362; Fri, 13 Feb 2004 10:11: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 1Arey8-0007fK-N4; Fri, 13 Feb 2004 10:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arexa-0007WB-FG for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 10:10:30 -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 KAA13154 for ; Fri, 13 Feb 2004 10:10:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArexX-0000wd-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:10:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArewP-0000na-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:09:18 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1ArevS-0000dA-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:08:18 -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 i1DF8557047504; Fri, 13 Feb 2004 10:08:15 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Margaret Wasserman'" , "'Ted Lemon'" Cc: "'Stig Venaas'" , "'Vijayabhaskar A K'" , "'DHCPWG'" , "'Harald Tveit Alvestrand'" Subject: RE: [dhcwg] [Fwd: Re: Dual stack issues] Date: Fri, 13 Feb 2004 10:08:06 -0500 Message-ID: <000001c3f243$3367ff10$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: <5.1.0.14.2.20040213082935.0426d120@ms101.mail1.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 Regarding this configuration example: 1) See my email from yesterday on how this would work at the client. The dual-stack client would, in this case, have the "alternate, DHCPv6 = first" setting and it would produce something fairly close: Node2: IPv6-Addr1, IPv4-Addr1, IPv6-Addr3, IPv4-Addr2, IPv4-Addr3, IPv4-Addr4 For DHCPv6 clients, that's likely what I would assume would be the = default. While this may not be optimum (since Server1 is listed twice and if down = it will take a bit longer to resolve names), it will still produce decent results. BTW, you're right that if there was some way for the node to know that IPv6-Addr1 and IPv4-Addr1 where the same host, it could perhaps remove = one of the addresses from the list (in which case you'd be left with your configuration). But, I think that's an optimization that isn't worth the effort. That may also be point of discussion - as to how "good" a = solution we need. I don't think we need one that is prefect under all conditions. 2) With DNS, does it really matter that much exactly what the order is. = The DNS protocol is transport agnostic, so it really shouldn't matter as the = DNS servers should all be pointing to the same DNS name space (which I = presume they'd better be!). Except for perhaps load balancing issues (such as round-robining the list for different clients), it really doesn't = matter. (There could also be connectivity issues I guess?) 3) I think better examples are things like dns search lists since these = are very order dependent (though some might argue that is bad since a = temporary DNS failure might return unexpected results - such as connecting to the wrong host). 4) I'm willing to allow IPv4-mapped addresses into DHCPv6 based options (such as the DNS servers). But I'm not convinced that this full solves = the problem. You still need some policy on a client for it to install the = proper set of options depending on what is available or not. 5) BTW, I presume node2 is using DHCPv6 to obtain the DNS information (Information-Request/Reply)? You don't mention this ("and Node2 uses = IPv6 autoconfiguration to generate IPv6 addresses"). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Margaret Wasserman Sent: Friday, February 13, 2004 8:54 AM To: Ted Lemon Cc: Stig Venaas; Vijayabhaskar A K; DHCPWG; Harald Tveit Alvestrand Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] At 04:10 PM 2/12/2004 -0500, Ted Lemon wrote: >It seems to me that it would be easier to just have a DHCP server that=20 >supports both DHCPv4 and DHCPv6 from the same configuration. I can=20 >easily imagine how to implement such a thing, and I think the = difficulty=20 >of administering it would be about the same as the difficulty of=20 >administering a DHCPv4-only server. This requires no new protocol=20 >nastiness, and provides a nice new product space in which the several = DHCP=20 >server vendors on this mailing list can compete. :') And how would the client put it back together? I really feel like we are having a classic failure to communicate... So, let me try an example. Let's suppose that I have a set of servers that provide a single service that is accessible via IPv4 of IPv6 transports. How do I configure all of the nodes in a network (that might include IPv4-only, dual-stack or, perhaps in the future, IPv6-only nodes) to reach that service? To be more specific: Let's say that I have 4 DNS Servers in my site. Let's say that I am only starting to roll out IPv6, so 2 of my DNS servers are dual-stack (providing service over IPv4 and IPv6 transports) and two of them are only available via the IPv4 transport. My servers could have the following IP addresses: Server1: IPv6-Addr1 IPv4-Addr1 Server2: IPv4-Addr2 Server3: IPv6-Addr3 IPv4-Addr3 Server4: IPv4-Addr4 Let's also assume that I have two nodes somewhere on my network, Node1 and Node2. Node1 is an IPv4-only node, and Node2 is a dual- stack (IPv4 and IPv6 node). Both nodes are configured to get their IPv4 addresses using DHCPv4, and Node2 uses IPv6 autoconfiguration to generate IPv6 addresses. Let's also assume that the DNS search list for each of these nodes should be in the order I have listed the servers above (Server1, Server2, Server3, Server4), and that I want the dual-stack node to use the IPv6 addresses for Server1 and Server3. So this is what I want to configure in each node's DNS server list: Node1: IPv4-Addr1, IPv4-Addr2, IPv4-Addr3, IPv4-Addr4 Node2: IPv6-Addr1, IPv4-Addr2, IPv6-Addr3, IPv4-Addr4 So, how do I do that? Well, I have to configure my DHCPv4 server to return all four of the IPv4 addresses, right? And, I guess you'd have me configure my DHCPv6 server to return only the two IPv6 addresses? So, Node1 will be configured correctly, but Node 2 will get _two_ lists of DNS server addresses (the IPv4 ones and the IPv6 ones). Which ones will it try first? There doesn't seem to be any priority or meta-information associated with any DHCP options that would allow Node2 to decide how to order the six entries it receives. There also doesn't seem to be a way for Node2 to know that two of the entries in the IPv4 table point to the same DNS servers as the two IPv6 entries. There seems to be some desire to sweep these decisions under the rug of "client implementation", but I can't see that our DHCPv6 options, as currently defined, are providing enough information for the client to make a reasonable choice. Margaret _______________________________________________ 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 Feb 13 10:28:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11099; Fri, 13 Feb 2004 09:43: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 1AreWz-0001I1-6k; Fri, 13 Feb 2004 09:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreW3-0001Et-Cp for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 09:42: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 JAA11017 for ; Fri, 13 Feb 2004 09:42:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AreW1-0005q6-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:42:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AreV8-0005lz-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:41:06 -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 1AreUQ-0005dn-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 09:40:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Feb 2004 06:47:48 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1DEdn4U029737 for ; Fri, 13 Feb 2004 06:39:50 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGA91429; Fri, 13 Feb 2004 09:39:48 -0500 (EST) Message-Id: <4.3.2.7.2.20040213093130.02a65b98@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Feb 2004 09:39:46 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-agentopt-radius-04.txt submitted for publication 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.0 required=5.0 tests=AWL 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: , I checked it out - Cisco would be willing to identify sections of draft-ietf-dhc-agentopt-radius-04.txt that are affected by our IPR statement. Other than that, we will not discuss any patent or patents until they are issued. I also looked into past experience with patent filing and issue dates. It will likely be years (rather than weeks or months) before any patent or patents impacting draft-ietf-dhc-agentopt-radius-04.txt are issued. - Ralph At 08:27 PM 2/12/2004 -0500, Ted Lemon wrote: >On Feb 12, 2004, at 5:28 PM, Ralph Droms wrote: >>Are there any objections to returning the document to the IESG for >>reconsideration? > >It sounds like you folks have some patent applications pending, and can't >talk about exactly what's covered. I think it might be best if the WG >waited until the patents were made public before making a decision on >this. It's possible that the patents don't actually apply to the option, >but just to what you're doing with 802.1x, and then there'd be no need for >people to worry about infringing if they implemented this draft. _______________________________________________ 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 Feb 13 10:31:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14928; Fri, 13 Feb 2004 10:31: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 1ArfHS-0004Ib-5l; Fri, 13 Feb 2004 10: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 1ArfGY-0004Fh-Fe for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 10:30:06 -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 KAA14875 for ; Fri, 13 Feb 2004 10:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfGW-0002j8-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:30:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfFa-0002fN-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:29:06 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1ArfEu-0002Wc-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:28:24 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i1DFRj8m000304; Fri, 13 Feb 2004 16:27:45 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i1DFRkW5002636; Fri, 13 Feb 2004 16:27:46 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 13 Feb 2004 16:27:46 +0100 From: Stig Venaas To: Bernie Volz Cc: "'Margaret Wasserman'" , "'Ted Lemon'" , "'Stig Venaas'" , "'Vijayabhaskar A K'" , "'DHCPWG'" , "'Harald Tveit Alvestrand'" Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] Message-ID: <20040213152746.GA2623@sverresborg.uninett.no> References: <5.1.0.14.2.20040213082935.0426d120@ms101.mail1.com> <000001c3f243$3367ff10$6401a8c0@BVolz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c3f243$3367ff10$6401a8c0@BVolz> User-Agent: Mutt/1.4.1i 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Fri, Feb 13, 2004 at 10:08:06AM -0500, Bernie Volz wrote: > Regarding this configuration example: > > 1) See my email from yesterday on how this would work at the client. The > dual-stack client would, in this case, have the "alternate, DHCPv6 first" > setting and it would produce something fairly close: > > Node2: IPv6-Addr1, IPv4-Addr1, IPv6-Addr3, IPv4-Addr2, IPv4-Addr3, > IPv4-Addr4 > > For DHCPv6 clients, that's likely what I would assume would be the default. > > While this may not be optimum (since Server1 is listed twice and if down it > will take a bit longer to resolve names), it will still produce decent > results. Yes, I think something like this could work. I got one idea/question. How easy would it be to have the dual-stack client, tell DHCPv4/DHCPv6 servers that it's only interested in some of the information? You could imagine that dual-stack client gets "IP neutral" data from v6 server, and then tell the v4 server that it only wants the v4 dependent data. Well, do you get the idea? I suppose the client could just ignore some of the info it gets anyway though, but how could you do something like this? You could perhaps even imagine that you give different answers to dual-stack and single-stack hosts in other cases. E.g. if you only use DHCPv4, you might want to give v4-only clients "example.com" as search path, while give dual-stack clients "ipv6.example.com example.com". Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 10:34:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15140; Fri, 13 Feb 2004 10:34: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 1ArfKL-0004Uh-S6; Fri, 13 Feb 2004 10: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 1ArfJT-0004RE-Kb for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 10:33: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 KAA15045 for ; Fri, 13 Feb 2004 10:33:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfJR-0002wY-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:33:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfIX-0002sP-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:32:09 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1ArfHr-0002o3-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 10:31:27 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1DFVE804832; Fri, 13 Feb 2004 22:31:14 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1DFSr006781; Fri, 13 Feb 2004 22:29:01 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: Ted Lemon , Stig Venaas , Vijayabhaskar A K , DHCPWG , Harald Tveit Alvestrand Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues] In-Reply-To: <5.1.0.14.2.20040213082935.0426d120@ms101.mail1.com> References: <5.1.0.14.2.20040213082935.0426d120@ms101.mail1.com> <20040212134801.GQ32618@sverresborg.uninett.no> <402B7FB1.9060504@india.hp.com> <20040212134801.GQ32618@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 2004 22:28:53 +0700 Message-ID: <2791.1076686133@munnari.OZ.AU> 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Fri, 13 Feb 2004 08:54:07 -0500 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20040213082935.0426d120@ms101.mail1.com> | So, how do I do that? You most probably don't, though other than as a strawman example to try and imagine non-existent differences, nor do you really want to. Ralph is totally correct, in real life, with any kind of sane management, these issues just don't arise (if the management is insane, that's a better thing to fix). If you're configuring the DNS, as in your example, what you want for each node is that its first back end resolver (not really DNS server, which is a different beast) give it correct answers, quickly. That's all that matters really - extra resolvers beyond that (and most clients only take 3 anyway, they ignore numbers 4, 5, 6. .... if you configure them) are used almost never (just if the first resolver goes down), and in that circumstance, you almost never really care which one gets used (the delay to determine that the first one is not responding is bothering the users enough) as long as something does - anything that the client can reach which is working is good enough (if you have to fall back as far as the 3rd in the list, most people have already gone out for lunch, and simply don't care). This is why I asked Harald for a *real* example where it makes a real difference - in practice, such things are very hard to find. And once more, this is *not* a v4 vs v6 issue. Exactly the same thing happens entirely within DHCPv4. A much more likely scenario is that I have 2 multi homed hosts, X and Y. Those are each connected to networks A and B. On each of A and B I have a DNS back end resolver (DA and DB). To even out the load, I want X to use DA, and Y to use DB. That is, provided that X's A interface is up and configured and working, and the same for Y's B interface (if not, then I want X to use DB, and Y to use DA respectively). That is, I configure the DHCP responses so that when X or Y asks for its address on net A, it gets told to use DA, when they ask for their address on net B, they get told to use DB (in each case I might list the other resolved as a second choice, or I might not - each has some advantages and some disadvantages). How exactly do I arrange for X and Y to end up with different orders when they both configure both interfaces? This problem is inherent in the way DHCP was "designed" since it bootstrapped itself out of BOOTP. If you want something that allows some kind of different configuration method, go and design some entirely new protocol, because DHCP just isn't what you are looking for. Whatever is designed should fix the "conflicting information from different servers on multiple interfaces" problem - once you've a method for that, the v4 vs v6 thing is just more of the same (one can treat v4 and v6 on the same hardware as being different logical interfaces). For the same protocol, and different interfaces, there are no "cute tricks" like using v4 compatible v6 addresses that will pretend to make everything nice, but really just cause problems. Good luck. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 12:09:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20543; Fri, 13 Feb 2004 12:09: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 1ArgoH-0005hG-K9; Fri, 13 Feb 2004 12:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgnS-0005cD-6n for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 12:08: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 MAA20486 for ; Fri, 13 Feb 2004 12:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgnQ-0004Ng-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:08:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Argmb-0004JJ-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:07:18 -0500 Received: from [208.236.67.14] (helo=gateway.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1Argli-0004EB-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:06:22 -0500 Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1DH6Jac006593 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 13 Feb 2004 12:06:20 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i1DH6DhV028008 for ; Fri, 13 Feb 2004 12:06:13 -0500 (EST) To: dhcwg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Vaibhav Kumar Date: Fri, 13 Feb 2004 12:06:10 -0500 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 6.5.1|January 21, 2004) at 02/13/2004 12:04:15, Serialize complete at 02/13/2004 12:04:15 Content-Type: multipart/alternative; boundary="=_alternative 005DF30D85256E39_=" 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 Subject: [dhcwg] server support of Relay agent info 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: , This is a multipart message in MIME format. --=_alternative 005DF30D85256E39_= Content-Type: text/plain; charset="us-ascii" Hello, Does anybody have any information on whether the generic relay agent information option and the link selection sub-option are supported by common DHCP server implementations? Does industry support exists today for these options, and if not, when can we expect this support. Any information would be a great help. Thanks. Vaibhav Kumar Hughes Network Systems Germantown, MD Tel: 301-601-7352 --=_alternative 005DF30D85256E39_= Content-Type: text/html; charset="us-ascii"
Hello,

Does anybody have any information on whether the generic relay agent information option and the link selection sub-option are supported by common DHCP server implementations? Does industry support exists today for these options, and if not, when can we expect this support.

Any information would be a great help. Thanks.

Vaibhav Kumar

Hughes Network Systems
Germantown, MD
Tel: 301-601-7352 --=_alternative 005DF30D85256E39_=-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 12:26:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21436; Fri, 13 Feb 2004 12:26: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 1Arh4j-00072E-M3; Fri, 13 Feb 2004 12:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh45-00071N-Nq for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 12:25: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 MAA21404 for ; Fri, 13 Feb 2004 12:25:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arh44-000647-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:25:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arh39-0005yx-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:24:24 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1Arh2U-0005qU-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:23:42 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.36 #1 (Debian)) id 1Arh1r-0005Eh-00; Fri, 13 Feb 2004 09:23:03 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Feb 2004 09:22:57 -0800 Message-ID: From: "Kostur, Andre" To: "'Vaibhav Kumar'" , dhcwg@ietf.org Subject: RE: [dhcwg] server support of Relay agent info option Date: Fri, 13 Feb 2004 09:22:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F256.05730880" 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=AWL,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_01C3F256.05730880 Content-Type: text/plain; charset="iso-8859-1" Yes. Many vendors support option 82 in general. I know that our implementation (Incognito Software) does support Link Selection, and I highly suspect that Cisco's does too. Ralph? -----Original Message----- From: Vaibhav Kumar [mailto:vakumar@hns.com] Sent: Friday, February 13, 2004 9:06 AM To: dhcwg@ietf.org Subject: [dhcwg] server support of Relay agent info option Hello, Does anybody have any information on whether the generic relay agent information option and the link selection sub-option are supported by common DHCP server implementations? Does industry support exists today for these options, and if not, when can we expect this support. Any information would be a great help. Thanks. Vaibhav Kumar Hughes Network Systems Germantown, MD Tel: 301-601-7352 ------_=_NextPart_001_01C3F256.05730880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] server support of Relay agent info option

Yes.  Many vendors support option 82 in = general.  I know that our implementation (Incognito Software) does = support Link Selection, and I highly suspect that Cisco's does = too.  Ralph?

-----Original Message-----
From: Vaibhav Kumar [mailto:vakumar@hns.com]
Sent: Friday, February 13, 2004 9:06 AM
To: dhcwg@ietf.org
Subject: [dhcwg] server support of Relay agent info = option

Hello,

Does anybody have any information on whether the = generic relay agent information option and the link selection = sub-option are supported by common DHCP server implementations? Does = industry support exists today for these options, and if not, when can = we expect this support.

Any information would be a great help. Thanks. =

Vaibhav Kumar

Hughes Network Systems
Germantown, MD
Tel: 301-601-7352

------_=_NextPart_001_01C3F256.05730880-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 12:36:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22010; Fri, 13 Feb 2004 12:36: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 1ArhEP-0007ok-6k; Fri, 13 Feb 2004 12:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhDg-0007mC-QO for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 12:35: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 MAA21896 for ; Fri, 13 Feb 2004 12:35:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhDf-00071j-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:35:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhCq-0006wO-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:34:24 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ArhCE-0006rL-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 12:33:46 -0500 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 1C4B01B22CA; Fri, 13 Feb 2004 11:21:53 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] server support of Relay agent info option Date: Fri, 13 Feb 2004 12:33:14 -0500 To: "Kostur, Andre" X-Mailer: Apple Mail (2.612) 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 On Feb 13, 2004, at 12:22 PM, Kostur, Andre wrote: > Yes.=A0 Many vendors support option 82 in general.=A0 I know that our=20= > implementation (Incognito Software) does support Link Selection, and I=20= > highly suspect that Cisco's does too.=A0 Ralph? Nominum supports the link selection suboption... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 14:17:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26793; Fri, 13 Feb 2004 14:17: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 1Ario9-0000my-N0; Fri, 13 Feb 2004 14: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 1ArinJ-0000fG-Bq for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 14:16:09 -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 OAA26677 for ; Fri, 13 Feb 2004 14:16:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArinG-00000a-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 14:16:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArimL-0007gi-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 14:15:10 -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 1ArilW-0007YT-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 14:14:19 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 13 Feb 2004 11:21:48 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1DJDk1m016574; Fri, 13 Feb 2004 11:13:46 -0800 (PST) Received: from kkinnear-w2k03.cisco.com ([161.44.65.247]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGB18552; Fri, 13 Feb 2004 14:13:45 -0500 (EST) Message-Id: <4.3.2.7.2.20040213141239.0277fa18@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Feb 2004 14:13:44 -0500 To: Vaibhav Kumar , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] server support of Relay agent info option Cc: kkinnear@cisco.com In-Reply-To: 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 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: , Vaibhav, The DHCP server in the Cisco Network Registrar product supports the link selection sub-option as well. Cheers -- Kim At 12:06 PM 2/13/2004, Vaibhav Kumar wrote: >Hello, > >Does anybody have any information on whether the generic relay agent information option and the link selection sub-option are supported by common DHCP server implementations? Does industry support exists today for these options, and if not, when can we expect this support. > >Any information would be a great help. Thanks. > >Vaibhav Kumar > >Hughes Network Systems >Germantown, MD >Tel: 301-601-7352 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 19:02:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16237; Fri, 13 Feb 2004 19:02: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 1ArnFx-0007vD-20; Fri, 13 Feb 2004 19:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArnFH-0007tW-SX for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 19:01: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 TAA16182 for ; Fri, 13 Feb 2004 19:01:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArnFE-0003JM-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 19:01:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArnEJ-0003EI-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 19:00:19 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1ArnDd-00037I-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 18:59:37 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HT100601RY7I1@mailout2.samsung.com> for dhcwg@ietf.org; Sat, 14 Feb 2004 08:58:55 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HT100EWWRY651@mailout2.samsung.com> for dhcwg@ietf.org; Sat, 14 Feb 2004 08:58:55 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HT100A4ARY62K@mmp1.samsung.com> for dhcwg@ietf.org; Sat, 14 Feb 2004 08:58:54 +0900 (KST) Date: Sat, 14 Feb 2004 08:58:46 +0900 From: "S. Daniel Park" To: dhcwg@ietf.org Cc: "'Vijayabhaskar A K'" , "'S. Daniel Park'" , Ralph Droms Message-id: <00a501c3f28d$54b11db0$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_ftk15zaptm4C1ibkh5oRRQ)" 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_50_60, HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] FW: Please publish attached draft [draft-ietf-dhc-dhcpv6-opt-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_ftk15zaptm4C1ibkh5oRRQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT I've submitted a revised draft as draft-ietf-dhc-dhcpv6-ctep-opt-01, but it didn't be published because of below reason; > Sorry this can not be updated as you submitted the -00 > right before the cut off. So I am posting an individual link as below; http://home.megapass.co.kr/~natpp00/01.txt Change log 1) fixed misalligned option format 2) added backgroud section to make sense what tunnel is considered in this draft Hope this help... Daniel --Boundary_(ID_ftk15zaptm4C1ibkh5oRRQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT FW: Please publish attached draft [draft-ietf-dhc-dhcpv6-opt-01]

I've submitted a revised draft as draft-ietf-dhc-dhcpv6-ctep-opt-01,
but it didn't be published because of below reason;

> Sorry this can not be updated as you submitted the -00
> right before the cut off.


So I am posting an individual link as below;
http://home.megapass.co.kr/~natpp00/01.txt

Change log
1) fixed misalligned option format
2) added backgroud section to make sense what tunnel is considered in this draft



Hope this help...


Daniel


--Boundary_(ID_ftk15zaptm4C1ibkh5oRRQ)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 13 19:39:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17083; Fri, 13 Feb 2004 19:39: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 1Arnpm-0001yx-PI; Fri, 13 Feb 2004 19:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmlL-0005h2-Le for dhcwg@optimus.ietf.org; Fri, 13 Feb 2004 18:30: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 SAA15139 for ; Fri, 13 Feb 2004 18:30:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmlI-00015a-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 18:30:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmkI-00011H-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 18:29:18 -0500 Received: from usen-221x249x121x227.ap-us01.usen.ad.jp ([221.249.121.227] helo=coconut.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1Armju-0000xu-00 for dhcwg@ietf.org; Fri, 13 Feb 2004 18:28:55 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 3E251FF; Sat, 14 Feb 2004 08:28:54 +0900 (JST) To: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040213232854.3E251FF@coconut.itojun.org> Date: Sat, 14 Feb 2004 08:28:54 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) 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 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: , >> draft-itojun-v6ops-v4mapped-harmful seems to be expired. Do we need to >> consider this still? 02 is not expired yet. it expires Apr 21, 2004. it seems that i-d editor put expiry notice (03) too early. itojun _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 14 10:47:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21897; Sat, 14 Feb 2004 10:47: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 1As20T-000601-D4; Sat, 14 Feb 2004 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 1As20F-0005zp-Qj for dhcwg@optimus.ietf.org; Sat, 14 Feb 2004 10:46: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 KAA21889 for ; Sat, 14 Feb 2004 10:46:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As20D-0005E0-00 for dhcwg@ietf.org; Sat, 14 Feb 2004 10:46:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As1zG-0005BK-00 for dhcwg@ietf.org; Sat, 14 Feb 2004 10:45:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1As1yR-00055f-00 for dhcwg@ietf.org; Sat, 14 Feb 2004 10:44:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2004 07:45:36 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1EFiF4U018159; Sat, 14 Feb 2004 07:44:15 -0800 (PST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-356.cisco.com [10.82.241.100]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA13982; Sat, 14 Feb 2004 07:44:14 -0800 (PST) Message-Id: <4.3.2.7.2.20040214054450.00c33870@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 14 Feb 2004 07:24:29 -0500 To: Ted Lemon From: John Schnizlein Subject: Re: [dhcwg] draft-ietf-dhc-agentopt-radius-04.txt submitted for publication Cc: dhcwg@ietf.org In-Reply-To: References: <4.3.2.7.2.20040212210425.02958e08@flask.cisco.com> <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> <4.3.2.7.2.20040212210425.02958e08@flask.cisco.com> 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.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , The purpose of agentopt-radius is to enable interoperation of network components. Blocking progress to an RFC would prevent the allocation of the code for this sub-option of the relay-agent information option. The result is not necessarily to prevent use of the idea, but it would require a vendor-specific solution. From a practical perspective, advancing this document is just about defining the sub-option so that everybody can use it. It does not require anybody to use it. Advancing the document is not endorsing the idea, just enabling others to interoperate with it. The reason for the patent application was to protect us from claims by others that they invented the idea and were entitled to compensation. This protects everyone, but since compensation is usually sought from a source with deep pockets, the company needs it. As you noted, Cisco's practice has been to defend its rights and promote interoperation, rather than to earn royalties. My protective intent in this application was reviewed and determined consistent with corporate policy. In my opinion, it is not possible to separate the patent from the use of this sub-option. Further elaboration of the details of the patent would not change this. Waiting for a patent award is blocking the sub-option. The utility of the idea will be proved (or disproved) in practice, but my opinion is that others should have the opportunity to interoperate with it, which is what is enabled by the proposed standard. Because you do not see enough utility to choose to participate now is not a very good reason to block progress that others might value. Since it is reasonable to balance potential utility against risk, consider the risk. Courts decide what is reasonable (which is why the new IETF RFCs on IPR don't define it). Courts tend to treat deception and misdirection harshly. It would be risky for a company to establish long-standing support of specifications for the purpose of interoperation, without any demand for royalties, and then later demand royalties without good reason. The amount of risk depends on how much can be lost, which sometimes means how much you have. There is no certainty here because courts sometimes decide in ways that surprise us. Regarding surprises, we agree that filing a statement on the (obscure) web site, which is unfortunately the best the IETF can require now, does not provide sufficient clarity. That is why we included a clear statement of the fact that there was a patent application in every version of our draft since November 2001. The alternatives are clear: enable interoperation with the sub-option, or block it with (indeterminate) delay until IPR issues are resolved. My opinion is that it would be unfair to block it now, after years of work, because of new demands for a royalty-free IPR statement. John At 10:08 PM 2/12/2004, Ted Lemon wrote: >On Feb 12, 2004, at 9:06 PM, Ralph Droms wrote: >>However, hypothetically speaking, if we can't talk about what's >>covered until, for example, a patent is actually granted, you >>might have to ask me to come out of retirement to explain it. > > From my side, I'm willing to wait. This is functionality I don't think is particularly useful, although it's certainly cool, and it requires a conforming DHCP implementation to be subject to the possibility of having to pay royalties (although I know Cisco's current practice is not to charge royalties in this case, it's still a potential risk down the road). > >I would be curious to know what the position of other wg members is on this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 14 12:54:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25205; Sat, 14 Feb 2004 12:54: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 1As3zN-0006n1-Hp; Sat, 14 Feb 2004 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3zC-0006mL-Cq for dhcwg@optimus.ietf.org; Sat, 14 Feb 2004 12:53: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 MAA25159 for ; Sat, 14 Feb 2004 12:53:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3zA-0005Da-00 for dhcwg@ietf.org; Sat, 14 Feb 2004 12:53:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3yC-00056A-00 for dhcwg@ietf.org; Sat, 14 Feb 2004 12:52:49 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1As3xF-0004zu-00 for dhcwg@ietf.org; Sat, 14 Feb 2004 12:51:50 -0500 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 06C701B2099; Sat, 14 Feb 2004 11:39:58 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040214054450.00c33870@wells.cisco.com> References: <4.3.2.7.2.20040212210425.02958e08@flask.cisco.com> <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> <4.3.2.7.2.20040212171054.02036ab0@flask.cisco.com> <4.3.2.7.2.20040212210425.02958e08@flask.cisco.com> <4.3.2.7.2.20040214054450.00c33870@wells.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D97FD58-5F16-11D8-A92D-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-agentopt-radius-04.txt submitted for publication Date: Sat, 14 Feb 2004 12:51:34 -0500 To: John Schnizlein X-Mailer: Apple Mail (2.612) 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 Egads, I don't have any objection to allocating an option code as a transport for some information. I just object to a standard that, if I implement it, subjects me to a possible royalty. If a server or client implementation of this option (not the technique that it enables, but the option itself) does not infringe, I have no immediate problem (I still would rather that the underlying protocol were unencumbered, but I'm not interested in fighting that battle). This is why I was asking for clarification of exactly what is covered. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 16 10:29:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24661; Mon, 16 Feb 2004 10:29:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askg8-0004Nd-Tj; Mon, 16 Feb 2004 10:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askfp-0004Mc-Fo for dhcwg@optimus.ietf.org; Mon, 16 Feb 2004 10:28:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24530; Mon, 16 Feb 2004 10:28:37 -0500 (EST) Message-Id: <200402161528.KAA24530@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, 16 Feb 2004 10:28:37 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-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 : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option Author(s) : R. Droms, J. Schnizlein Filename : draft-ietf-dhc-agentopt-radius-04.txt Pages : 9 Date : 2004-2-13 A network access device may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of an IP address for assignment to the device through its DHCP client. The RADIUS Attributes sub-option allows a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-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-agentopt-radius-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-agentopt-radius-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: <2004-2-16104026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentopt-radius-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16104026.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 16 10:34:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25403; Mon, 16 Feb 2004 10: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 1Askl5-000538-2c; Mon, 16 Feb 2004 10:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskkV-0004oj-Nq for dhcwg@optimus.ietf.org; Mon, 16 Feb 2004 10:33: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 KAA25243 for ; Mon, 16 Feb 2004 10:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AskkT-0004Yw-00 for dhcwg@ietf.org; Mon, 16 Feb 2004 10:33:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskjW-0004VG-00 for dhcwg@ietf.org; Mon, 16 Feb 2004 10:32:30 -0500 Received: from tapti.adventnet.co.in ([203.199.211.109] helo=mail-hub.india.adventnet.com) by ietf-mx with esmtp (Exim 4.12) id 1Askj4-0004RE-00 for dhcwg@ietf.org; Mon, 16 Feb 2004 10:32:04 -0500 Received: from smtp.india.adventnet.com (smtp [192.168.4.41]) by mail-hub.india.adventnet.com (8.12.8/8.12.8) with ESMTP id i1GFW9Dg028667 for ; Mon, 16 Feb 2004 21:02:09 +0530 Received: from adventnet.com (gsaravanan [192.168.9.237]) by smtp.india.adventnet.com (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id i1GFVxq1015835 for ; Mon, 16 Feb 2004 21:01:59 +0530 Message-ID: <4030E34E.9030609@adventnet.com> Date: Mon, 16 Feb 2004 21:05:42 +0530 From: saravanan Reply-To: gsaravanan@adventnet.com Organization: Adventnet India Pvt Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.3(snapshot 20030212) (mail-hub) 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] dhcp options 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 Hai, I am new for dhcp world. I've configured dhcp & dyndns server on diff machines.I want to update dns from dhcp. Is there any option in dhcpd.conf to specify the dns server address by which I can update? Dhcp server tries to update locally(dyn.dns on same machine) by default. Note: ----- I am using the following option for the clients to have dns server's names ' option domain-name-servers 192.168.1.10' where 192.168.1.10 --> my dns slave. I don't want the clients to query from my master dns. So that I want to exclude my master server here. Pls help me Sarav _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 17 10:32:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04893; Tue, 17 Feb 2004 10:32: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 1At7Cb-0000OV-Ox; Tue, 17 Feb 2004 10:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7CB-0000KX-B8 for dhcwg@optimus.ietf.org; Tue, 17 Feb 2004 10:31:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04599; Tue, 17 Feb 2004 10:31:31 -0500 (EST) Message-Id: <200402171531.KAA04599@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, 17 Feb 2004 10:31:30 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-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 : Node-Specific Client Identifiers for DHCPv4 Author(s) : T. Lemon Filename : draft-ietf-dhc-3315id-for-v4-02.txt Pages : 8 Date : 2004-2-17 This document specifies the format that is to be used for encoding DHCPv4 (RFC2131/RFC2132) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol (RFC3315). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-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-3315id-for-v4-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-3315id-for-v4-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: <2004-2-17103137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-3315id-for-v4-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-3315id-for-v4-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17103137.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 Feb 17 14:20:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28149; Tue, 17 Feb 2004 14:20: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 1AtAlI-0002tp-A2; Tue, 17 Feb 2004 14:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAkX-0002qs-Ht for dhcwg@optimus.ietf.org; Tue, 17 Feb 2004 14:19: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 OAA28045 for ; Tue, 17 Feb 2004 14:19:14 -0500 (EST) From: margaret@thingmagic.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAkV-0004Gx-00 for dhcwg@ietf.org; Tue, 17 Feb 2004 14:19:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAjX-0004C8-00 for dhcwg@ietf.org; Tue, 17 Feb 2004 14:18:16 -0500 Received: from [208.232.239.2] (helo=tswordip) by ietf-mx with smtp (Exim 4.12) id 1AtAic-00047E-00 for dhcwg@ietf.org; Tue, 17 Feb 2004 14:17:18 -0500 Date: Tue, 17 Feb 2004 13:22:43 -0600 To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------724766768846545" 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=MICROSOFT_EXECUTABLE, NO_REAL_NAME autolearn=no version=2.60 Subject: [dhcwg] ID jyvcknx... thanks 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: , ----------724766768846545 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yours ID tfiyknpl -- Thank ----------724766768846545 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: orlqpsvda.exe, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ----------724766768846545-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From salnoticiaurgente@hotmail.com Thu Feb 19 12:44:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29257 for ; Thu, 19 Feb 2004 12:44:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsEP-0003h2-00 for dhc-archive@ietf.org; Thu, 19 Feb 2004 12:45:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsDW-0003Zx-00 for dhc-archive@ietf.org; Thu, 19 Feb 2004 12:44:08 -0500 Received: from [211.46.20.130] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AtsCL-0003NS-00; Thu, 19 Feb 2004 12:42:54 -0500 From: "Mato Grosso: . cao" To: dhc-archive@ietf.org Subject: Alertam sobre perigo de aftosa em fazendas invadidas por índios ref.: vge User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Thu, 19 Feb 2004 12:42:54 -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=8.1 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,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.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.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 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

cod.: (ntf) EnEspañol:TraductorGratuitoAutomático - InEnglish:FreeAutomaticTranslator

Mato Grosso do Sul: alertam sobre perigo de aftosa em fazendas invadidas por índios

Conselho Indigenista Missionário (Cimi), Fundação Nacional do Índio (Funai) e ONGs são acusadas de "fabricar" conflitos entre índios e proprietários rurais, que já causaram numerosas vítimas, como um dirigente pecuarista recentemente assassinado em Santa Catarina

CAMPO GRANDE, Fevr. 19, 2004 (AB) - "Há uma preocupação enorme com relação ao estado sanitário do rebanho bovino estimado em 9 mil cabeças, nas 14 fazendas invadidas por índios na região de Japorã, perto da fronteira com o Paraguai". "Mato Grosso do Sul é livre de aftosa, mediante vacinação, o Estado possui o 1o. rebanho bovino do Brasil, e um dos primeiros do mundo, com 24 milhões e 700 mil cabeças, contribuindo com uma porcentagem significativa das exportações de carne bovina. Qualquer brote de aftosa que venha a macular esse estado sanitário teria de imediato uma enorme repercussão econômica em nível local, nacional e internacional". O alerta foi dado ontem pelo engenheiro Josiel Quintino dos Santos, assessor de Meio Ambiente e Assuntos Indígenas da Federação da Agricultura e Pecuária de Mato Grosso do Sul (Famasul) (DrQuintino:DesejoContato - DrQuintino:DesejoContatoDeImprensa). A tensão e a violência na região fez com que a Agência Estadual de Defesa Sanitária Animal e Vegetal (Iagro) tenha suspendido o trabalho de vigilância e vacinação do rebanho das fazendas invadidas por índios guaranis, caiuás e ñandeva.

Quintino acrescentou a preocupação existente no Estado "com os conflitos fabricados e incentivados pelo Conselho Indigenista Missionário (Cimi), e favorecidos pela Fundação Nacional do Índio, segundo já foi documentado no relatório da CPI do Funai, na Câmara dos Deputados". O assessor da Famasul informou que os índios, contrariamente ao informado por alguns meios de imprensa, "não abandonaram nenhuma das 14 fazendas invadidas, e até o momento não permitiram o trabalho de perícia judicial para avaliar a destruição causada".

Brasília: deputado Zauith denúncia "manipulação" de índios

Também ontem, em Brasília, o deputado sul-matogrossense Murilo Zauith (PFL) fez discurso na tribuna da Câmara para "denunciar os conflitos indígenas" que vem ocorrendo em todo o País, incentivados pela "atuação de determinadas organizações internacionais, que chegam a ameaçar a soberania nacional" e de "pessoas inescrupulosas" que "manipulam" e "incitam os índios a invadir as propriedades rurais". Zauith acrescentou que esse "cenário devastador" já vem causando "uma retração nos investimentos no agronegócio em Mato Grosso do Sul", atividade que "é o principal pilar da economia sul-matogrossense" (DepZauith:DiscursoCompleto).

Santa Catarina: Cimi e Funai fomentam caos, diz Federação da Agricultura

A Federação da Agricultura do Estado de Santa Catarina (Faesc), em nota de repúdio diante do assassinato do pecuarista Olisses Stefani, recentemente vitimado com um tiro de carabina na cabeça por indígenas que ameaçavam invadir propriedades rurais, afirma que sua morte "revela a dramática dimensão a que chegaram os conflitos entre índios e produtores no grande Oeste catarinense". E acrescenta que "determinadas organizações, motivadas por objetivos inconfessáveis, fomentam o embate e exasperam a crise, tentando criar um cenário de caos e desordem", sendo "notória, nesse aspecto, a ação do Conselho Indigenista Missionário (Cimi), cujos agentes imiscuem-se nas áreas indígenas para fomentar a discórdia". Enquanto a Fundação Nacional do Índio (Funai) oscila entre a inércia e a omissão, nada fazendo em favor da paz e da tranqüilidade", sendo sua atuação "marcada pela influência de ONGs" (Faesc:TextoCompleto).

040219AB / Atualidade Brasileira

 LINKS:

DrQuintino/Famasul:DesejoContato

DrQuintino/Famasul:DesejoContatoUrgente

DrQuintino/Famasul:DesejoContatoDeImprensa

DepZauith:DiscursoCompleto

Faesc:TextoCompleto

AtualidadeBrasileira:MinhaOpinião

AtualidadeBrasileira:Concordo

AtualidadeBrasileira:Discordo

AtualidadeBrasileira:DocumentaçãoUsada

AtualidadeBrasileira:Remover

A difusão deste comunicado, com uma finalidade exclusivamente informativa, é de responsabilidade da agência Atualidade Brasileira (Rio de Janeiro). O texto pode ser reproduzido parcial ou totalmente, sendo recomendável, mas não necessário, citar a fonte.

 

 

From dhcwg-admin@ietf.org Thu Feb 19 19:40:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06933; Thu, 19 Feb 2004 19:40: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 1Atyi2-00074J-QV; Thu, 19 Feb 2004 19:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyhV-00073C-2d for dhcwg@optimus.ietf.org; Thu, 19 Feb 2004 19:39: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 TAA06845 for ; Thu, 19 Feb 2004 19:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyhT-0007RK-00 for dhcwg@ietf.org; Thu, 19 Feb 2004 19:39:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtygW-0007P2-00 for dhcwg@ietf.org; Thu, 19 Feb 2004 19:38:29 -0500 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 1Atyfx-0007NJ-00 for dhcwg@ietf.org; Thu, 19 Feb 2004 19:37:53 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp011.mail.yahoo.com with SMTP; 20 Feb 2004 00:37:52 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Thu, 19 Feb 2004 16:42:56 -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) 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] ANNOUNCEMENT: conference call to discuss DHCP implementation issues for STD review 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 Continuing the discussion begun in October here on the DHCWG mailing list and continued at the Minneapolis IETF meeting, I'm announcing a telephone conference call to discuss the implementation issues prior to revising or reaffirming RFC 2131 so that it can advance to Internet Standard status. Respond to me by e-mail (rbhibbs@pacbell.net) so I can arrange with our benefactor for a conference bridge of sufficient size. Items for discussion include: 1. Do we have sufficient response from the community to proceed? 2. Accept or reject typographic corrections 3. Policy issues: any proposed wording changes? 4. Invariability of 'chaddr' 5. Clarification of the Client Identifier (eliminate suggested format) 6. Address in use detection: can we improve it? 7. Relay agent source addresses and port usage 8. Can we eliminate the 'sname' and 'file' fields of the BOOTP packet? 9. Accept, reject, or further study SHOULD v. MUST changes 10. Review of other issues as time permits 11. Schedule follow-on review of unresolved issues 12. Identify RFC2131bis editors 13. Identify interest and initial reviewers for RFC2132 --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 19 19:49:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07654; Thu, 19 Feb 2004 19:49: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 1Atyqj-0007cm-Nt; Thu, 19 Feb 2004 19:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyqI-0007cI-In for dhcwg@optimus.ietf.org; Thu, 19 Feb 2004 19:48:34 -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 TAA07626 for ; Thu, 19 Feb 2004 19:48:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyqG-0000YM-00 for dhcwg@ietf.org; Thu, 19 Feb 2004 19:48:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtypM-0000W2-00 for dhcwg@ietf.org; Thu, 19 Feb 2004 19:47:37 -0500 Received: from smtp015.mail.yahoo.com ([216.136.173.59]) by ietf-mx with smtp (Exim 4.12) id 1Atyp0-0000TA-00 for dhcwg@ietf.org; Thu, 19 Feb 2004 19:47:14 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp015.mail.yahoo.com with SMTP; 20 Feb 2004 00:47:14 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Thu, 19 Feb 2004 16:52:17 -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) 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 Subject: [dhcwg] FW: ANNOUNCEMENT: conference call to discuss DHCP implementation issues for STD review 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 Left out the time in the prior message. Continuing the discussion begun in October here on the DHCWG mailing list and continued at the Minneapolis IETF meeting, I'm announcing a telephone conference call to discuss the implementation issues prior to revising or reaffirming RFC 2131 so that it can advance to Internet Standard status. >> >>The call will be Monday, 23 Feb 2004, from 1200 ET until 1400 ET.<< >> Respond to me by e-mail (rbhibbs@pacbell.net) so I can arrange with our benefactor for a conference bridge of sufficient size. Items for discussion include: 1. Do we have sufficient response from the community to proceed? 2. Accept or reject typographic corrections 3. Policy issues: any proposed wording changes? 4. Invariability of 'chaddr' 5. Clarification of the Client Identifier (eliminate suggested format) 6. Address in use detection: can we improve it? 7. Relay agent source addresses and port usage 8. Can we eliminate the 'sname' and 'file' fields of the BOOTP packet? 9. Accept, reject, or further study SHOULD v. MUST changes 10. Review of other issues as time permits 11. Schedule follow-on review of unresolved issues 12. Identify RFC2131bis editors 13. Identify interest and initial reviewers for RFC2132 --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 20 10:18:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27151; Fri, 20 Feb 2004 10:18:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCPs-0007cg-AS; Fri, 20 Feb 2004 10:18:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCPS-0007Rn-Ed for dhcwg@optimus.ietf.org; Fri, 20 Feb 2004 10:17: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 KAA26948 for ; Fri, 20 Feb 2004 10:17:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuCPQ-00000T-00 for dhcwg@ietf.org; Fri, 20 Feb 2004 10:17:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuCNW-0007P0-00 for dhcwg@ietf.org; Fri, 20 Feb 2004 10:15:47 -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 1AuCL6-0006wn-00 for dhcwg@ietf.org; Fri, 20 Feb 2004 10:13:16 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1KFCZ4W003450 for ; Fri, 20 Feb 2004 07:12:37 -0800 (PST) Received: from insbu-view1.cisco.com (insbu-view1.cisco.com [171.71.160.12]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGE80447; Fri, 20 Feb 2004 10:12:33 -0500 (EST) Date: Fri, 20 Feb 2004 07:12:33 -0800 (PST) From: Ralph Droms To: dhcwg@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: FWD: RFC Copyrights and Disclaimers for IPRs (fwd) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , FYI, for those of you who use xml2rfc and friends. And, I *highly* recommend you check out these tools for RFCs and I-Ds if you don't already use them... - Ralph ---------- Forwarded message ---------- Date: Fri, 20 Feb 2004 06:56:17 -0800 From: Marshall Rose To: wgchairs@ietf.org Subject: Re: FWD: RFC Copyrights and Disclaimers for IPRs > Following the publication of BCP 78 (RFC 3667), BCP 79 (RFC 3668), and > RFC 3669 on Feb 18, 2004, the RFC Editor has begun to incorporate into > all documents slated for RFC publication the copyright and intellectual > property rights statements called for by these documents. > ... this weekend, there will be a new release of the rfc2629-based tools (xml2rfc and julian's xslt) that supports these changes for RFCs and I-Ds. /mtr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 22 18:50:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14193; Sun, 22 Feb 2004 18:50: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 1Av3MI-0004lr-KF; Sun, 22 Feb 2004 18:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av3M9-0004l4-ND for dhcwg@optimus.ietf.org; Sun, 22 Feb 2004 18:49:53 -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 SAA14190 for ; Sun, 22 Feb 2004 18:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av3M6-0003XO-00 for dhcwg@ietf.org; Sun, 22 Feb 2004 18:49:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av3L8-0003Ty-00 for dhcwg@ietf.org; Sun, 22 Feb 2004 18:48:50 -0500 Received: from smtp103.mail.sc5.yahoo.com ([66.163.169.222]) by ietf-mx with smtp (Exim 4.12) id 1Av3KJ-0003Qn-00 for dhcwg@ietf.org; Sun, 22 Feb 2004 18:47:59 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp103.mail.sc5.yahoo.com with SMTP; 22 Feb 2004 23:47:58 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Sun, 22 Feb 2004 15:53:11 -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) 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 Subject: [dhcwg] ANNOUNCEMENT: RFC 2131 Implementation Issues Conference Call Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As previously announced, the DHC Working Group will hold a conference call tomorrow (Monday) to discuss the issues raised by "draft-ietf-dhc-implementation-01.txt" and discussed at IETF-58 in Minneapolis. Items for discussion include: 1. Do we have sufficient response from the community to proceed? 2. Accept or reject typographic corrections 3. Policy issues: any proposed wording changes? 4. Invariability of 'chaddr' 5. Clarification of the Client Identifier (eliminate suggested format) 6. Address in use detection: can we improve it? 7. Relay agent source addresses and port usage 8. Can we eliminate the 'sname' and 'file' fields of the BOOTP packet? 9. Accept, reject, or further study SHOULD v. MUST changes 10. Review of other issues as time permits 11. Schedule follow-on review of unresolved issues 12. Identify RFC2131bis editors 13. Identify interest and initial reviewers for RFC2132 14. Set date and time for follow-up conference call (if needed) Call-in information for the conference bridge, thoughtfully provided by Cisco Systems, is: Meeting Date/Start Time: February 23, 2004, 1700 GMT/1200 ET/0900 PT Meeting Duration: 2 hours MeetingID: 7322131 (RFC2131) Meeting Access Phone Numbers: Local San Jose (area code 408) & International: +1-408-902-7873 Domestic US Toll Free (Outside San Jose ONLY): +1-866-902-7873 ***This number WILL NOT work from the 408 area code.*** The conference bridge will accommodate 12 callers only. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 23 08:23:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23736; Mon, 23 Feb 2004 08:23: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 1AvG33-0006Dt-23; Mon, 23 Feb 2004 08: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 1AvG2G-0006Be-Ui for dhcwg@optimus.ietf.org; Mon, 23 Feb 2004 08:22: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 IAA23659 for ; Mon, 23 Feb 2004 08:22:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvG2F-0001Ok-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 08:22:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvG1L-0001M8-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 08:21:15 -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 1AvG1C-0001J7-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 08:21:06 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Feb 2004 05:31:11 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1NDKYuA002500 for ; Mon, 23 Feb 2004 05:20:34 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-94.cisco.com [10.86.240.94]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGF84148; Mon, 23 Feb 2004 08:20:33 -0500 (EST) Message-Id: <4.3.2.7.2.20040223080421.02864870@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Feb 2004 08:20:31 -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.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Subject: [dhcwg] Scribes and Jabber scribe for dhc WG meeting in Seoul 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: , Let me know if you're willing to volunteer to act as scribe for the WG meeting in Seoul. The dhc WG meeting is scheduled for Tue, 3/2, 0900-1130 (Seoul). If I have my conversions correct, that time is equivalent to: 3/2 0530 IST 3/2 0000 UTC 3/1 1900 EST 3/1 1600 PST I plan to make a Jabber session available, so let me know if you're interested in joining the Jabber session. If you will attend the meeting in person, let me know if you're willing to act as a Jabber scribe. Thanks... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 23 09:41:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28218; Mon, 23 Feb 2004 09:41: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 1AvHGV-0006L5-Sz; Mon, 23 Feb 2004 09:40:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHFn-0006IG-6I for dhcwg@optimus.ietf.org; Mon, 23 Feb 2004 09:40:15 -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 JAA28166 for ; Mon, 23 Feb 2004 09:40:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvHFl-0000fy-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 09:40:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvHEq-0000co-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 09:39:16 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AvHDt-0000Wz-00; Mon, 23 Feb 2004 09:38:17 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2004 06:35:16 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1NEbjT4010610; Mon, 23 Feb 2004 09:37:45 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-94.cisco.com [10.86.240.94]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGF88711; Mon, 23 Feb 2004 09:37:44 -0500 (EST) Message-Id: <4.3.2.7.2.20040223093640.0287a3d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Feb 2004 09:37:43 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Revised agenda for dhc WG meeting 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: , DHC WG agenda - IETF 59 0900 Tue 03/04/2004 (tentative) (Last revised 02/23/2004 09:35 AM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing DHCP Option for Proxy Server Configuration 05 minutes Technical discussion; ready for WG last call? The Extended Remote Boot Option for DHCPv4 05 minutes Technical discussion; ready for WG last call? DHCPv6 Support for Remote Boot 05 minutes Technical discussion; ready for WG last call? Configured Tunnel End Point Option for DHCPv6 Daniel Park 05 minutes Technical discussion; ready for WG last call? DHCPv4 Support for Configuring IPv6-in-IPv4 Tunnels Daniel Park 05 minutes Technical discussion; ready for WG last call? Requirements for Proposed Changes to DHCPv4 05 minutes Technical discussion; ready for WG last call? Node-Specific Client Identifiers for DHCPv4 05 minutes Technical discussion; ready for WG last call? Rapid Commit Option for DHCPv4 05 minutes Technical discussion; ready for WG last call? Micro-block IP Address Allocation With DHCP Proxy Server Naiming Shen 05 minutes Accept as WG work item? Renumbering Requirements for Stateless DHCPv6 Stig Venaas 10 minutes Accept as WG work item? Lifetime Option for DHCPv6 Stig Venaas 10 minutes Accept as WG work item? Vendor-Specific Suboption for the DHCP Relay Agent Option 05 minutes Accept as WG work item? Discussion of dual-stack (DHCPv4/DHCPv6) issues Ralph Droms 15 minutes IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Stig Venaas 10 minutes Accept as WG work item? DHCPv6 IPv4 Information Options 10 minutes Accept as WG work item? Update on IPR issue with two drafts Ralph Droms 15 minutes Update of dhc WG charter Ralph Droms 15 minutes ----------- Total 140 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 23 14:51:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15331; Mon, 23 Feb 2004 14:51: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 1AvM6X-0003BR-No; Mon, 23 Feb 2004 14: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 1AvM5v-0003Ad-Ua for dhcwg@optimus.ietf.org; Mon, 23 Feb 2004 14:50: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 OAA15283 for ; Mon, 23 Feb 2004 14:50:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvM5t-0005V5-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 14:50:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvM4u-0005R4-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 14:49:21 -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 1AvM3x-0005LX-00; Mon, 23 Feb 2004 14:48:22 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1NJlkuC013069; Mon, 23 Feb 2004 11:47:48 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-94.cisco.com [10.86.240.94]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG18939; Mon, 23 Feb 2004 14:47:44 -0500 (EST) Message-Id: <4.3.2.7.2.20040223144653.01facef0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Feb 2004 14:47:42 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Revised agenda for dhc WG meeting 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: , DHC WG agenda - IETF 59 0900 Tue 03/04/2004 (tentative) (Last revised 02/23/2004 02:45 PM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing DHCP Option for Proxy Server Configuration 05 minutes Technical discussion; ready for WG last call? The Extended Remote Boot Option for DHCPv4 05 minutes Technical discussion; ready for WG last call? Vendor-Identifying Vendor Options for DHCPv4 Ralph Droms 05 minutes Technical discussion; ready for WG last call? Requirements for Proposed Changes to DHCPv4 05 minutes Technical discussion; ready for WG last call? Node-Specific Client Identifiers for DHCPv4 05 minutes Technical discussion; ready for WG last call? Rapid Commit Option for DHCPv4 05 minutes Technical discussion; ready for WG last call? DHCPv6 Support for Remote Boot 05 minutes Technical discussion; ready for WG last call? Configured Tunnel End Point Option for DHCPv6 Soohong Daniel Park 05 minutes Technical discussion; ready for WG last call? DHCPv4 Support for Configuring IPv6-in-IPv4 Tunnels Soohong Daniel Park 05 minutes Accept as WG work item? Micro-block IP Address Allocation With DHCP Proxy Server Naiming Shen 05 minutes Accept as WG work item? Renumbering Requirements for Stateless DHCPv6 Stig Venaas 10 minutes Accept as WG work item? Lifetime Option for DHCPv6 Stig Venaas 10 minutes Accept as WG work item? Vendor-Specific Suboption for the DHCP Relay Agent Option 05 minutes Accept as WG work item? Introduction to dual-stack (DHCPv4/DHCPv6) issues Ralph Droms 05 minutes IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Stig Venaas 20 minutes Accept as WG work item? DHCPv6 IPv4 Information Options 10 minutes Accept as WG work item? Update of dhc WG charter Ralph Droms 15 minutes Update on IPR issue with two drafts Ralph Droms 15 minutes ----------- Total 145 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 23 14:58:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15622; Mon, 23 Feb 2004 14:58: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 1AvMDJ-0003Y8-J4; Mon, 23 Feb 2004 14:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMCp-0003XN-Ex for dhcwg@optimus.ietf.org; Mon, 23 Feb 2004 14:57: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 OAA15580 for ; Mon, 23 Feb 2004 14:57:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMCm-00061w-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 14:57:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMBz-0005xg-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 14:56:40 -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 1AvMB4-0005nR-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 14:55:42 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Feb 2004 12:05:46 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1NJt44W010139 for ; Mon, 23 Feb 2004 11:55:06 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-94.cisco.com [10.86.240.94]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG19695; Mon, 23 Feb 2004 14:55:03 -0500 (EST) Message-Id: <4.3.2.7.2.20040223144809.0287a3d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Feb 2004 14:55:00 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Revised agenda for dhc WG meeting In-Reply-To: <4.3.2.7.2.20040223093640.0287a3d0@flask.cisco.com> 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.0 required=5.0 tests=AWL 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: , My apologies for the profusion of draft agendas... Please review the following drafts and post comments to dhcwg@ietf.org in preparation for the WG meeting in Seoul. Review for WG last call: ------------------------ DHCP Option for Proxy Server Configuration The Extended Remote Boot Option for DHCPv4 Vendor-Identifying Vendor Options for DHCPv4 Requirements for Proposed Changes to DHCPv4 Node-Specific Client Identifiers for DHCPv4 Rapid Commit Option for DHCPv4 DHCPv6 Support for Remote Boot Configured Tunnel End Point Option for DHCPv6 Review for acceptance as WG work item: -------------------------------------- DHCPv4 Support for Configuring IPv6-in-IPv4 Tunnels Micro-block IP Address Allocation With DHCP Proxy Server Renumbering Requirements for Stateless DHCPv6 Lifetime Option for DHCPv6 Vendor-Specific Suboption for the DHCP Relay Agent Option IPv4 and IPv6 Dual-Stack Issues for DHCPv6 DHCPv6 IPv4 Information Options _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 23 19:45:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05275; Mon, 23 Feb 2004 19:45: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 1AvQh5-0006Gv-0E; Mon, 23 Feb 2004 19: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 1AvQgd-0006FD-EY for dhcwg@optimus.ietf.org; Mon, 23 Feb 2004 19:44: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 TAA05239 for ; Mon, 23 Feb 2004 19:44:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvQgb-0001DR-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 19:44:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvQfh-0001AC-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 19:43:37 -0500 Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx with smtp (Exim 4.12) id 1AvQfO-00016m-00 for dhcwg@ietf.org; Mon, 23 Feb 2004 19:43:18 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp102.mail.sc5.yahoo.com with SMTP; 24 Feb 2004 00:43:09 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Mon, 23 Feb 2004 16:48:24 -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) 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 Subject: [dhcwg] ANNOUNCEMENT: second conference call discussing dhcpv4 implementation issues I-D 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 second conference call to discuss this draft will be held on Wednesday, 25 February, 2004, starting at 1600 GMT/1100 ET/0800 PT. The agenda will be to continue through our section-by-section review of the draft, starting with section 2.11. Following this call a summary document describing the discussions and our resolutions will be posted to the mailing list. Anyone not attending today's meeting may still participate, but please respond as soon as possible to myself and Ralph Droms so we can arrange an appropriate conference bridge -- again, thanks to Cisco Systems for their kind support. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 03:29:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06381; Tue, 24 Feb 2004 03:29: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 1AvXw5-0000UX-4Z; Tue, 24 Feb 2004 03: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 1AvXvr-0000Tr-OK for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 03:28:47 -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 DAA06348 for ; Tue, 24 Feb 2004 03:28:46 -0500 (EST) From: stefaan.de_cnodder@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvXvp-0001R5-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 03:28:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvXuq-0001Lj-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 03:27:44 -0500 Received: from gc-na165.alcatel.fr ([64.208.49.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AvXtq-0001DV-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 03:26:42 -0500 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1O8Qfes010572; Tue, 24 Feb 2004 09:26:41 +0100 Received: from alcatel.be ([138.203.87.210]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004022409264014:1470 ; Tue, 24 Feb 2004 09:26:40 +0100 Message-ID: <403B0ABF.F1A59333@alcatel.be> Date: Tue, 24 Feb 2004 09:26:39 +0100 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: naiming@redback.com CC: dhcwg@ietf.org Subject: microblock allocation Re: [dhcwg] Revised agenda for dhc WG meeting References: <4.3.2.7.2.20040223144809.0287a3d0@flask.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/24/2004 09:26:40, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/24/2004 09:26:40, Serialize complete at 02/24/2004 09:26:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes 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=NO_REAL_NAME 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 Hi, > > Micro-block IP Address Allocation With DHCP Proxy Server > > In the above draft, how many IP addresses from a Micro-block are available for clients? In section 3 it is mentioned that 1 address is used "on the router", and I guess also the IP addresses where the host part is all 1's are all 0's are not allowed to be used by clients. This makes the example in section 4.1 inaccurate: 5000 clients with micro-blocks of 32 gives an efficiency of 90% (instead of 99.5% as mentioned in the draft). Is this correct? Section 4.3 says that a DHCP server MUST NOT set both both flags in the micro-blocking suboption. A DHCP server not supporting this, will return it to the proxy with both flags set. Some text should be added to say what a proxy is supposed to do when the response contains this suboption with prefix length still equal to zero, i.e. the proxy must assume that the DHCP server does not support it, although both flags could be set. regards, Stefaan _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 10:35:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26466; Tue, 24 Feb 2004 10:35: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 1AveaM-0005Fg-DQ; Tue, 24 Feb 2004 10: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 1AveZe-0005Ei-0Z for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 10:34: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 KAA26439 for ; Tue, 24 Feb 2004 10:34:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AveZb-0001nY-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:34:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AveYc-0001iv-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:33:15 -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 1AveYC-0001dq-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:32:48 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2004 07:43:06 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1OFWG4U024760; Tue, 24 Feb 2004 07:32:16 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG83431; Tue, 24 Feb 2004 10:32:14 -0500 (EST) Message-Id: <4.3.2.7.2.20040224102345.02aeb118@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Feb 2004 10:32:11 -0500 To: joshl@cisco.com From: Ralph Droms Cc: dhcwg@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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] vendor-01 comments 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 specification looks OK to me. I do have one small suggestion: for clarification, add a sentence that explicitly describes how multiple enterprise numbers are encoded in a single instance of each option. The text does imply that multiple instances of the vendor-specific data can appear in an instance of each option; adding the sentence I suggest would make that implication explicit and ensure there is no question about the format of such options. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 10:39:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26691; Tue, 24 Feb 2004 10:39: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 1AveeD-0005i1-I1; Tue, 24 Feb 2004 10: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 1AvedI-0005b9-ER for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 10:38: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 KAA26604 for ; Tue, 24 Feb 2004 10:38:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvedF-00026D-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:38:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvecR-00022q-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:37:12 -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 1Avec4-0001yO-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:36:49 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2004 07:47:05 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1OFaFuA024772 for ; Tue, 24 Feb 2004 07:36:16 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG83718; Tue, 24 Feb 2004 10:36:14 -0500 (EST) Message-Id: <4.3.2.7.2.20040224103234.02aee970@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Feb 2004 10:36:12 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] daniel-dhc-ipv6in4-opt comments 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 think this document is ready to be accepted as dhc WG work item. Making this option a DHCPv4 option allows a dual stack host to bootstrap itself into a disconnected IPv6 infrastructure - for example, a dual-stack host on an IPv4-only link. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 10:58:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27293; Tue, 24 Feb 2004 10:58: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 1Avewa-0000se-MW; Tue, 24 Feb 2004 10:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avevv-0000r0-6w for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 10:57: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 KAA27259 for ; Tue, 24 Feb 2004 10:57:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avevs-0003nU-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:57:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aveuv-0003h8-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:56:18 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AveuC-0003Wk-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 10:55:32 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2004 07:57:37 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1OFsvT6001386 for ; Tue, 24 Feb 2004 10:55:00 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG85692; Tue, 24 Feb 2004 10:54:56 -0500 (EST) Message-Id: <4.3.2.7.2.20040224105004.02b03560@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Feb 2004 10:54:54 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] rapid-commit-opt comments 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 think this specification is ready for WG last call. I have only a couple of editorial suggestions about text that describes the policy of when the Rapid Commit option. In section 3, I suggest editing the text to indicate that a client and server only use the Rapid Commit option when configured to do so. For example, the first sentence in section 3 implies to me that the client uses the Rapid Commit option whenever it has code that can process the option, without allowing for local configuration that disables use of the option. In section 3.2, list item 2, I think the first sentence is unnecessary and "plentiful" isn't helpful; the second sentence describes the problem in sufficient detail to guide DHCP service admins. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 11:04:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27620; Tue, 24 Feb 2004 11:04: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 1Avf2O-0001S0-PY; Tue, 24 Feb 2004 11: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 1Avf1T-0001R4-MM for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 11:03: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 LAA27566 for ; Tue, 24 Feb 2004 11:02:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avf1R-0004Lt-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 11:03:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avf0S-0004HI-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 11:02:00 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AvezV-00049Z-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 11:01:01 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2004 07:57:28 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1OG0ST4002651; Tue, 24 Feb 2004 11:00:28 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG86289; Tue, 24 Feb 2004 11:00:27 -0500 (EST) Message-Id: <4.3.2.7.2.20040224105648.02af9df8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Feb 2004 11:00:25 -0500 To: "S. Daniel Park" From: Ralph Droms Subject: RE: [dhcwg] Comments on "Configured Tunnel End Point Option for DHCPv6" Cc: dhcwg@ietf.org In-Reply-To: <01e301c3f038$660fc450$67cadba8@LocalHost> References: <4.3.2.7.2.20040210174302.02864790@flask.cisco.com> 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.0 required=5.0 tests=AWL 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: , I understand this option to be passing the IPv6 address of the local endpoint of configured tunnel to a host; that is, the IPv6 address of some device that is reachable via IPv6 from the host. If I have that right, wouldn't the reachability to the external IPv6 network (through the tunnel) be advertised through a routing protocol? Why would this option be necessary? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 12:07:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29707; Tue, 24 Feb 2004 12:07: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 1Avg1N-0007GX-U3; Tue, 24 Feb 2004 12: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 1Avg0h-0007FG-2Q for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 12:06: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 MAA29662 for ; Tue, 24 Feb 2004 12:06:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avg0f-0002sp-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 12:06:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avfzi-0002mC-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 12:05:18 -0500 Received: from smtp016.mail.yahoo.com ([216.136.174.113]) by ietf-mx with smtp (Exim 4.12) id 1Avfz0-0002f1-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 12:04:34 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.117.51 with login) by smtp016.mail.yahoo.com with SMTP; 24 Feb 2004 16:57:58 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Tue, 24 Feb 2004 09:03:16 -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) 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 Subject: [dhcwg] ANNOUNCEMENT: RFC 2131 implementation issues review conference call Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The second conference call reviewing the draft document coving RFC 2131 implementation issues will be held tomorrow, Wednesday, 25 February, 2004. Call details: Start Date/Time: February 25, 2004, 1600 GMT/1100 ET/0800 PT Meeting ID: 7322131 Meeting Access Phone Numbers: Local San Jose (area code 408) & International : +1-408-902-7873 Domestic Toll Free (Outside San Jose ONLY) : +1-866-902-7873 ***This number WILL NOT work from the 408 area code.*** The conference bridge will accommodate 12 participants. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 14:03:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04207; Tue, 24 Feb 2004 14:03: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 1Avhpe-0007Ul-BC; Tue, 24 Feb 2004 14:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhop-0007OR-FV for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 14:02:11 -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 OAA04149 for ; Tue, 24 Feb 2004 14:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avhon-00069P-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 14:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avhnt-00063o-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 14:01:13 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1Avhms-0005wL-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 14:00:10 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 071DE66F666; Tue, 24 Feb 2004 11:00:09 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26653-09; Tue, 24 Feb 2004 11:00:08 -0800 (PST) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 1642166F66B; Tue, 24 Feb 2004 11:00:08 -0800 (PST) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id LAA02726; Tue, 24 Feb 2004 11:00:07 -0800 (PST) Message-Id: <200402241900.LAA02726@redback.com> To: stefaan.de_cnodder@alcatel.be Cc: dhcwg@ietf.org Subject: Re: microblock allocation Re: [dhcwg] Revised agenda for dhc WG meeting In-reply-to: Mail from stefaan.de_cnodder@alcatel.be dated Tue, 24 Feb 2004 09:26:39 +0100 <403B0ABF.F1A59333@alcatel.be> Date: Tue, 24 Feb 2004 11:00:07 -0800 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.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 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 Stefaan, ] Hi, ] ] > Micro-block IP Address Allocation With DHCP Proxy Server ] > ] > ] In the above draft, how many IP addresses from a Micro-block are available ] for clients? In section 3 it is mentioned that 1 address is used "on the ] router", and I guess also the IP addresses where the host part is all 1's ] are all 0's are not allowed to be used by clients. This makes the example ] in section 4.1 inaccurate: 5000 clients with micro-blocks of 32 gives an ] efficiency of 90% (instead of 99.5% as mentioned in the draft). Is this ] correct? It depends. If the router address allocation is for the PPP clients or any clients over point-to-point connections, ALL the IP addresses in a block is available to the clients/users. But if the address allocation is for PPPoE clients, normal IPoE clients or hosts over a LAN connection, then we(the routers) need to take 3 addresses out of that. The above mentioned efficiency just list the maximum which is in p2p case. ] ] Section 4.3 says that a DHCP server MUST NOT set both both flags in the ] micro-blocking suboption. A DHCP server not supporting this, will return it ] to the proxy with both flags set. Some text should be added to say what a ] proxy is supposed to do when the response contains this suboption with ] prefix length still equal to zero, i.e. the proxy must assume that the DHCP ] server does not support it, although both flags could be set. Ok. What the current version of the draft does not mention is the handling of errored condition, such as both bits set, zero prefix-len returned, etc. Will update those in the next version. thanks for the suggestion. Best Regards, - Naiming ] ] regards, ] ] Stefaan _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 15:07:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07209; Tue, 24 Feb 2004 15:07: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 1Avipa-0001kz-AM; Tue, 24 Feb 2004 15:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avip0-0001Ok-Ot for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 15:06:26 -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 PAA07083 for ; Tue, 24 Feb 2004 15:06:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aviox-00045r-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 15:06:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avinw-0003xw-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 15:05:20 -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 1Avina-0003se-00; Tue, 24 Feb 2004 15:04:58 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1OK4P1m010468; Tue, 24 Feb 2004 12:04:26 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGH11938; Tue, 24 Feb 2004 15:04:24 -0500 (EST) Message-Id: <4.3.2.7.2.20040224150232.02b46b28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Feb 2004 15:04:22 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Revised agenda for dhc WG meeting 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: , DHC WG agenda - IETF 59 0900 Tue 03/04/2004 (tentative) (Last revised 02/24/2004 11:43 AM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing DHCP Option for Proxy Server Configuration Vijay AK 03 minutes Technical discussion; ready for WG last call? The Extended Remote Boot Option for DHCPv4 Vijay AK 03 minutes Technical discussion; ready for WG last call? Vendor-Identifying Vendor Options for DHCPv4 Ralph Droms 03 minutes Technical discussion; ready for WG last call? Requirements for Proposed Changes to DHCPv4 03 minutes Technical discussion; ready for WG last call? Node-Specific Client Identifiers for DHCPv4 Ted Lemon 03 minutes Technical discussion; ready for WG last call? Rapid Commit Option for DHCPv4 Ralph Droms 03 minutes Technical discussion; ready for WG last call? DHCPv6 Support for Remote Boot Vijay AK 03 minutes Technical discussion; ready for WG last call? Configured Tunnel End Point Option for DHCPv6 S D Park 03 minutes Technical discussion; ready for WG last call? Reclassifying DHCPv4 Options Ralph Droms 03 minutes Technical discussion; ready for WG last call? DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels S D Park 05 minutes Accept as WG work item? Micro-block IP Addr. Alloc. With DHCP Proxy Server Naiming Shen 05 minutes Accept as WG work item? Vendor-Specific Suboption for the DHCP RAIO 05 minutes Accept as WG work item? Renumbering Requirements for Stateless DHCPv6 Stig Venaas 10 minutes Accept as WG work item? Lifetime Option for DHCPv6 Stig Venaas 10 minutes Accept as WG work item? Multicast Reconf. Protocol for Stateless DHCPv6 Vijay AK 10 minutes Accept as WG work item? Introduction to dual-stack (DHCPv4/DHCPv6) issues Ralph Droms 05 minutes IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Stig Venaas 20 minutes Accept as WG work item? DHCPv6 IPv4 Information Options 10 minutes Accept as WG work item? Update of dhc WG charter Ralph Droms 15 minutes Update on IPR issue with two drafts Ralph Droms 15 minutes ----------- Total 142 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 16:10:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11302; Tue, 24 Feb 2004 16:10: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 1AvjoZ-0002SC-5b; Tue, 24 Feb 2004 16:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjo1-0002PZ-K5 for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 16:09: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 QAA11227 for ; Tue, 24 Feb 2004 16:09:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjnz-0002mJ-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:09:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjn0-0002fW-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:08:26 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1Avjm4-0002Ze-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:07:28 -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 i1OL7GGn023869; Tue, 24 Feb 2004 16:07:25 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , Cc: Subject: RE: [dhcwg] vendor-01 comments Date: Tue, 24 Feb 2004 16:07:25 -0500 Message-ID: <004401c3fb1a$36db2980$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.20040224102345.02aeb118@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 I also wonder whether for completeness the following issues should be addressed: - Are these options allowed in DHCPINFORMs (I see no reason why not). = Might it be good to state the messages these option may appear in: = DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPINFORM? - In order for a server to send back vendor-specific information option, MUST the client send a vendor-specific information option (with the enterprise number and perhaps data-len of 0 if it has no options)? Or, = is a server allowed to send vendor-specific information option if, for = example, just a vendor-class option is sent or the server somehow determines the vendor (or just sends the option anyway). - I think I know what you are recommending, but might it be best to = clarify what is meant by: "so implementations SHOULD attempt to format instances = of these new vendor options such that they can be interpreted without concatenation, if support for RFC 3396 is in doubt."=20 - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Tuesday, February 24, 2004 10:32 AM To: joshl@cisco.com Cc: dhcwg@ietf.org Subject: [dhcwg] vendor-01 comments This specification looks OK to me. I do have one small suggestion: for clarification, add a sentence that explicitly describes how multiple enterprise numbers are encoded in a = single instance of each option. The text does imply that multiple instances of the vendor-specific data = can appear in an instance of each option; adding the sentence I suggest = would make that implication explicit and ensure there is no question about the format of such options. - 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 Feb 24 16:46:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12964; Tue, 24 Feb 2004 16:46: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 1AvkNN-0004dl-Tn; Tue, 24 Feb 2004 16: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 1AvkMa-0004Zc-Vh for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 16:45: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 QAA12910 for ; Tue, 24 Feb 2004 16:45:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvkMY-0006AO-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:45:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvkLb-00064T-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:44:11 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AvkKd-0005xV-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:43:11 -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 i1OLgx57078600; Tue, 24 Feb 2004 16:43:07 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , Cc: "'Ralph Droms'" , Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments Date: Tue, 24 Feb 2004 16:43:07 -0500 Message-ID: <004501c3fb1f$340c38c0$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.20040224103234.02aee970@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 Hi: Some comments on daniel-dhc-ipv6in4-opt-01.txt (I hope this is the = latest): - What exactly is the subnet mask used for? I don't understand why this field is present for each address. The address is a IPv4 destination = address of the router (or host) to which IPv6 packets can be tunneled over IPv4 = and I see no reason why a subnet mask is needed (a single address serves as = the tunnel, not an entire subnet?). Perhaps this was supposed to be IPv6 network information (address + = prefix length)? But from what RFC 2893 says, this doesn't make sense either = since this is supposed to be a last resort route. This is partially reinforced = in section 4 of the draft: The list of end-points can be installed as the default routes and=20 the routes will be tried in a round robin fashion if the IPv6 host=20 load-sharing is honored [5]. Instead there can be specific default = routes for the different destination. But, the last sentence is troublesome as how can specific default routes = be installed for different destinations (unless IPv6 information is somehow communicated). I think what you might want for each tunnel endpoint is: - IPv4 address of the tunnel endpoint - IPv6 address and prefix-length for the IPv6 network reachable through the tunnel. Encoding this could be done in a variable number of bytes: - IPv4 address is fixed 4-bytes - IPv6 prefix-length is 1 byte - IPv6 address is from 0 to 16 bytes depending on length. For the more likely last resort routes (for all non-local IPv6 traffic), you'd only use 5 bytes - 4 for IPv4 address and 1 for prefix-length of = 0. - If the subnet mask is needed: a. "The minimum length of this option is 4, and the length MUST be a multiple of 4" is incorrect as it should be 8 and multiple of 8. b. It might be better if 5 bytes were used to represent this - address followed by a subnet length. This is a more compact form and will keep packet sizes down. Hopefully I'm completely confused. And if so, that might also point out something about the draft? Perhaps references to [4] should have an = explicit section number to help? Or the terminology should be consistent ... [4] = uses "Configured tunneling of IPv6 over IPv4", this draft uses different language, "IPv6-in-IPv4 configured tunnel". - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Tuesday, February 24, 2004 10:36 AM To: dhcwg@ietf.org Subject: [dhcwg] daniel-dhc-ipv6in4-opt comments I think this document is ready to be accepted as dhc WG work item. Making this option a DHCPv4 option allows a dual stack host to bootstrap itself into a disconnected IPv6 infrastructure - for example, a = dual-stack host on an IPv4-only link. - 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 Feb 24 16:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13341; Tue, 24 Feb 2004 16:56: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 1AvkX5-00051A-4C; Tue, 24 Feb 2004 16:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvkWN-0004zC-MY for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 16:55:20 -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 QAA13302 for ; Tue, 24 Feb 2004 16:55:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvkWL-00070z-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:55:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvkVR-0006vg-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:54:21 -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 1AvkUb-0006mO-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 16:53:30 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2004 14:03:51 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1OLqv4U029202; Tue, 24 Feb 2004 13:52:57 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-103.cisco.com [10.86.242.103]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGH23276; Tue, 24 Feb 2004 16:52:55 -0500 (EST) Message-Id: <4.3.2.7.2.20040224164824.01f88f98@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Feb 2004 16:52:52 -0500 To: From: Ralph Droms Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments Cc: , In-Reply-To: <004501c3fb1f$340c38c0$6401a8c0@BVolz> References: <4.3.2.7.2.20040224103234.02aee970@flask.cisco.com> 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.0 required=5.0 tests=AWL 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: , Bernie - I think you're exactly right, each entry should include: * IPv4 tunnel endpoint address * IPv6 prefix length * IPv6 prefix The receiving host encapsulates and forwards any IPv6 datagrams that match the IPv6 prefix in an IPv4 datagram sent to the IPv4 tunnel endpoint address. I also agree that we might consider carrying the IPv6 prefix as a variable length data item, with the length as required by the prefix length. - Ralph At 04:43 PM 2/24/2004 -0500, Bernie Volz wrote: >Hi: > >Some comments on daniel-dhc-ipv6in4-opt-01.txt (I hope this is the latest): > >- What exactly is the subnet mask used for? I don't understand why this >field is present for each address. The address is a IPv4 destination address >of the router (or host) to which IPv6 packets can be tunneled over IPv4 and >I see no reason why a subnet mask is needed (a single address serves as the >tunnel, not an entire subnet?). > >Perhaps this was supposed to be IPv6 network information (address + prefix >length)? But from what RFC 2893 says, this doesn't make sense either since >this is supposed to be a last resort route. This is partially reinforced in >section 4 of the draft: > > The list of end-points can be installed as the default routes and > the routes will be tried in a round robin fashion if the IPv6 host > load-sharing is honored [5]. Instead there can be specific default > routes for the different destination. > >But, the last sentence is troublesome as how can specific default routes be >installed for different destinations (unless IPv6 information is somehow >communicated). > >I think what you might want for each tunnel endpoint is: > - IPv4 address of the tunnel endpoint > - IPv6 address and prefix-length for the IPv6 network reachable >through the tunnel. > >Encoding this could be done in a variable number of bytes: > - IPv4 address is fixed 4-bytes > - IPv6 prefix-length is 1 byte > - IPv6 address is from 0 to 16 bytes depending on length. > >For the more likely last resort routes (for all non-local IPv6 traffic), >you'd only use 5 bytes - 4 for IPv4 address and 1 for prefix-length of 0. > >- If the subnet mask is needed: > >a. "The minimum length of this option is 4, and the length MUST be a >multiple of 4" is incorrect as it should be 8 and multiple of 8. > >b. It might be better if 5 bytes were used to represent this - address >followed by a subnet length. This is a more compact form and will keep >packet sizes down. > > >Hopefully I'm completely confused. And if so, that might also point out >something about the draft? Perhaps references to [4] should have an explicit >section number to help? Or the terminology should be consistent ... [4] uses >"Configured tunneling of IPv6 over IPv4", this draft uses different >language, "IPv6-in-IPv4 configured tunnel". > >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph >Droms >Sent: Tuesday, February 24, 2004 10:36 AM >To: dhcwg@ietf.org >Subject: [dhcwg] daniel-dhc-ipv6in4-opt comments > >I think this document is ready to be accepted as dhc WG work item. > >Making this option a DHCPv4 option allows a dual stack host to bootstrap >itself into a disconnected IPv6 infrastructure - for example, a dual-stack >host on an IPv4-only link. > >- 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 Feb 24 19:05:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18093; Tue, 24 Feb 2004 19:05: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 1AvmXt-0001wV-Ik; Tue, 24 Feb 2004 19:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvmXC-0001vz-GY for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 19:04: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 TAA18079 for ; Tue, 24 Feb 2004 19:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvmX9-0001VJ-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:04:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvmWD-0001Ro-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:03:18 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AvmVN-0001OT-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:02:25 -0500 Received: from [10.255.204.233] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 50F911B3EC9; Tue, 24 Feb 2004 17:48:53 -0600 (CST) In-Reply-To: <004401c3fb1a$36db2980$6401a8c0@BVolz> References: <004401c3fb1a$36db2980$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Ralph Droms'" , , From: Ted Lemon Subject: Re: [dhcwg] vendor-01 comments Date: Tue, 24 Feb 2004 19:02:26 -0500 To: "Bernie Volz" X-Mailer: Apple Mail (2.612) 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 On Feb 24, 2004, at 4:07 PM, Bernie Volz wrote: > - I think I know what you are recommending, but might it be best to > clarify > what is meant by: "so implementations SHOULD attempt to format > instances of > these new vendor options such that they can be interpreted without > concatenation, if support for RFC 3396 is in doubt." You should just specify that support for RFC3396 is required. There's no reason why a server that supports this option shouldn't also support RFC3396. RFC3396 says how to handle concatenation, and it's easy to specify it badly (who knows, maybe RFC3396 specifies it badly), so it's better not to respecify it in this draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 19:17:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18736; Tue, 24 Feb 2004 19: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 1AvmjU-0002ps-W5; Tue, 24 Feb 2004 19:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avmiu-0002mp-V5 for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 19:16:24 -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 TAA18613 for ; Tue, 24 Feb 2004 19:16:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avmit-0002eI-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:16:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avmhn-0002Ut-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:15:16 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1Avmgo-0002HS-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:14:14 -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 <0HTM004075YUDR@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 09:13:42 +0900 (KST) Received: from ep_mmp1 (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 <0HTM00FNO5YT8M@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 09:13:42 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTM00C5W5YT6I@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 09:13:41 +0900 (KST) Date: Wed, 25 Feb 2004 09:13:43 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] rapid-commit-opt comments In-reply-to: <4.3.2.7.2.20040224105004.02b03560@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Cc: "'S. Daniel Park'" Message-id: <003d01c3fb34$3ac9ca00$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Ralph It sounds reasonable, I will make sure the comments end up in the next draft. Regards - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Ralph Droms > Sent: Wednesday, February 25, 2004 12:55 AM > To: dhcwg@ietf.org > Subject: [dhcwg] rapid-commit-opt comments > > > I think this specification is ready for WG last call. > > I have only a couple of editorial suggestions about text that > describes the > policy of when the Rapid Commit option. > > In section 3, I suggest editing the text to indicate that a client and > server only use the Rapid Commit option when configured to do so. For > example, the first sentence in section 3 implies to me that > the client uses > the Rapid Commit option whenever it has code that can process > the option, > without allowing for local configuration that disables use of > the option. > > In section 3.2, list item 2, I think the first sentence is > unnecessary and > "plentiful" isn't helpful; the second sentence describes the > problem in > sufficient detail to guide DHCP service admins. > > - 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 Feb 24 19:59:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19858; Tue, 24 Feb 2004 19:59: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 1AvnO9-00051l-Ci; Tue, 24 Feb 2004 19:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvnNa-00051T-2B for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 19:58:26 -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 TAA19824 for ; Tue, 24 Feb 2004 19:58:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvnNX-00063D-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:58:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvnMa-0005zH-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:57:25 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AvnMG-0005uq-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 19:57:04 -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 <0HTM006017YAI5@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 09:56:34 +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 <0HTM00F587Y98M@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 09:56:33 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTM00GXS7Y92Q@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 09:56:33 +0900 (KST) Date: Wed, 25 Feb 2004 09:56:35 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments In-reply-to: <4.3.2.7.2.20040224164824.01f88f98@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Cc: kimps@samsung.com, "'S. Daniel Park'" , Bernie Volz Message-id: <004301c3fb3a$377e60d0$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 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 Thanks for letting me consider these ! All what indicated by Bernie is reasonable and I'll make sure the changes end up in the next draft. PS: Don't we need a tuples to installl the routes on the client like < Prefix/prefix-len, Configured TEP IPv4 Address > ? Regards - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Ralph Droms > Sent: Wednesday, February 25, 2004 6:53 AM > To: dhcwg@ietf.org > Cc: kimps@samsung.com; soohong.park@samsung.com > Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments > > > Bernie - I think you're exactly right, each entry should include: > > * IPv4 tunnel endpoint address > * IPv6 prefix length > * IPv6 prefix > > The receiving host encapsulates and forwards any IPv6 > datagrams that match > the IPv6 prefix in an IPv4 datagram sent to the IPv4 tunnel > endpoint address. > > I also agree that we might consider carrying the IPv6 prefix > as a variable > length data item, with the length as required by the prefix length. > > - Ralph > > At 04:43 PM 2/24/2004 -0500, Bernie Volz wrote: > >Hi: > > > >Some comments on daniel-dhc-ipv6in4-opt-01.txt (I hope this > is the latest): > > > >- What exactly is the subnet mask used for? I don't > understand why this > >field is present for each address. The address is a IPv4 > destination address > >of the router (or host) to which IPv6 packets can be > tunneled over IPv4 and > >I see no reason why a subnet mask is needed (a single > address serves as the > >tunnel, not an entire subnet?). > > > >Perhaps this was supposed to be IPv6 network information > (address + prefix > >length)? But from what RFC 2893 says, this doesn't make > sense either since > >this is supposed to be a last resort route. This is > partially reinforced in > >section 4 of the draft: > > > > The list of end-points can be installed as the default > routes and > > the routes will be tried in a round robin fashion if > the IPv6 host > > load-sharing is honored [5]. Instead there can be > specific default > > routes for the different destination. > > > >But, the last sentence is troublesome as how can specific > default routes be > >installed for different destinations (unless IPv6 > information is somehow > >communicated). > > > >I think what you might want for each tunnel endpoint is: > > - IPv4 address of the tunnel endpoint > > - IPv6 address and prefix-length for the IPv6 > network reachable > >through the tunnel. > > > >Encoding this could be done in a variable number of bytes: > > - IPv4 address is fixed 4-bytes > > - IPv6 prefix-length is 1 byte > > - IPv6 address is from 0 to 16 bytes depending on length. > > > >For the more likely last resort routes (for all non-local > IPv6 traffic), > >you'd only use 5 bytes - 4 for IPv4 address and 1 for > prefix-length of 0. > > > >- If the subnet mask is needed: > > > >a. "The minimum length of this option is 4, and the length MUST be a > >multiple of 4" is incorrect as it should be 8 and multiple of 8. > > > >b. It might be better if 5 bytes were used to represent this > - address > >followed by a subnet length. This is a more compact form and > will keep > >packet sizes down. > > > > > >Hopefully I'm completely confused. And if so, that might > also point out > >something about the draft? Perhaps references to [4] should > have an explicit > >section number to help? Or the terminology should be > consistent ... [4] uses > >"Configured tunneling of IPv6 over IPv4", this draft uses different > >language, "IPv6-in-IPv4 configured tunnel". > > > >- Bernie > > > >-----Original Message----- > >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Ralph > >Droms > >Sent: Tuesday, February 24, 2004 10:36 AM > >To: dhcwg@ietf.org > >Subject: [dhcwg] daniel-dhc-ipv6in4-opt comments > > > >I think this document is ready to be accepted as dhc WG work item. > > > >Making this option a DHCPv4 option allows a dual stack host > to bootstrap > >itself into a disconnected IPv6 infrastructure - for > example, a dual-stack > >host on an IPv4-only link. > > > >- Ralph > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 20:26:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20910; Tue, 24 Feb 2004 20:26: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 1AvnoI-0006Wk-7Q; Tue, 24 Feb 2004 20:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avnne-0006W0-EM for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 20:25:22 -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 UAA20896 for ; Tue, 24 Feb 2004 20:25:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avnnc-0000az-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 20:25:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avnmj-0000XO-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 20:24:26 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AvnmT-0000TL-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 20:24:09 -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 i1P1NlGn075535; Tue, 24 Feb 2004 20:24:01 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'S. Daniel Park'" Cc: , "'Ralph Droms'" , Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments Date: Tue, 24 Feb 2004 20:23:55 -0500 Message-ID: <005b01c3fb3e$0c6314f0$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: <004301c3fb3a$377e60d0$67cadba8@LocalHost> 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 Hi: Not sure exactly what you mean, but yes for each configured tunnel = endpoint you need three items (a tuple): - IPv4 address of the tunnel endpoint (4-bytes) - IPv6 prefix length for the IPv6 route to the tunnel endpoint (1-byte) - IPv6 prefix for the route ... (prefix length/8 bytes) When the prefix length is 0, no prefix is needed (since it is 0). You = can put them in any order you like, but to compress the information, you'll = need to put the prefix length before the prefix. Are the prefix length and prefix really needed? Will routing information (RAs) arrive over the tunnel that might already supply this (and thus = avoid the need for configuration through DHCPv4)? If multiple tunnels exist, = one could assume they are like IPv4 default routes and the routing = information should eventually get sorted out such that the proper tunnel is used? (Ralph's comment regarding the DHCPv6 tunneling option draft made we = wonder about this issue here as well.) - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of S. Daniel Park Sent: Tuesday, February 24, 2004 7:57 PM To: 'Ralph Droms'; dhcwg@ietf.org Cc: kimps@samsung.com; 'S. Daniel Park'; Bernie Volz Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments Thanks for letting me consider these ! All what indicated by Bernie is reasonable and I'll make sure the changes end up in the next draft. PS: Don't we need a tuples to installl the routes on the client=20 like < Prefix/prefix-len, Configured TEP IPv4 Address > ? Regards - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics.=20 > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of Ralph Droms > Sent: Wednesday, February 25, 2004 6:53 AM > To: dhcwg@ietf.org > Cc: kimps@samsung.com; soohong.park@samsung.com > Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments >=20 >=20 > Bernie - I think you're exactly right, each entry should include: >=20 > * IPv4 tunnel endpoint address > * IPv6 prefix length > * IPv6 prefix >=20 > The receiving host encapsulates and forwards any IPv6=20 > datagrams that match > the IPv6 prefix in an IPv4 datagram sent to the IPv4 tunnel=20 > endpoint address. >=20 > I also agree that we might consider carrying the IPv6 prefix=20 > as a variable > length data item, with the length as required by the prefix length. >=20 > - Ralph >=20 > At 04:43 PM 2/24/2004 -0500, Bernie Volz wrote: > >Hi: > > > >Some comments on daniel-dhc-ipv6in4-opt-01.txt (I hope this=20 > is the latest): > > > >- What exactly is the subnet mask used for? I don't=20 > understand why this > >field is present for each address. The address is a IPv4=20 > destination address > >of the router (or host) to which IPv6 packets can be=20 > tunneled over IPv4 and > >I see no reason why a subnet mask is needed (a single=20 > address serves as the > >tunnel, not an entire subnet?). > > > >Perhaps this was supposed to be IPv6 network information=20 > (address + prefix > >length)? But from what RFC 2893 says, this doesn't make=20 > sense either since > >this is supposed to be a last resort route. This is=20 > partially reinforced in > >section 4 of the draft: > > > > The list of end-points can be installed as the default=20 > routes and > > the routes will be tried in a round robin fashion if=20 > the IPv6 host > > load-sharing is honored [5]. Instead there can be=20 > specific default > > routes for the different destination. > > > >But, the last sentence is troublesome as how can specific=20 > default routes be > >installed for different destinations (unless IPv6=20 > information is somehow > >communicated). > > > >I think what you might want for each tunnel endpoint is: > > - IPv4 address of the tunnel endpoint > > - IPv6 address and prefix-length for the IPv6=20 > network reachable > >through the tunnel. > > > >Encoding this could be done in a variable number of bytes: > > - IPv4 address is fixed 4-bytes > > - IPv6 prefix-length is 1 byte > > - IPv6 address is from 0 to 16 bytes depending on length. > > > >For the more likely last resort routes (for all non-local=20 > IPv6 traffic), > >you'd only use 5 bytes - 4 for IPv4 address and 1 for=20 > prefix-length of 0. > > > >- If the subnet mask is needed: > > > >a. "The minimum length of this option is 4, and the length MUST be a > >multiple of 4" is incorrect as it should be 8 and multiple of 8. > > > >b. It might be better if 5 bytes were used to represent this=20 > - address > >followed by a subnet length. This is a more compact form and=20 > will keep > >packet sizes down. > > > > > >Hopefully I'm completely confused. And if so, that might=20 > also point out > >something about the draft? Perhaps references to [4] should=20 > have an explicit > >section number to help? Or the terminology should be=20 > consistent ... [4] uses > >"Configured tunneling of IPv6 over IPv4", this draft uses different > >language, "IPv6-in-IPv4 configured tunnel". > > > >- Bernie > > > >-----Original Message----- > >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of Ralph > >Droms > >Sent: Tuesday, February 24, 2004 10:36 AM > >To: dhcwg@ietf.org > >Subject: [dhcwg] daniel-dhc-ipv6in4-opt comments > > > >I think this document is ready to be accepted as dhc WG work item. > > > >Making this option a DHCPv4 option allows a dual stack host=20 > to bootstrap > >itself into a disconnected IPv6 infrastructure - for=20 > example, a dual-stack > >host on an IPv4-only link. > > > >- Ralph > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ 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 Feb 24 21:52:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23315; Tue, 24 Feb 2004 21:52: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 1Avp9U-00032g-PU; Tue, 24 Feb 2004 21:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avp90-00030y-AD for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 21:51:30 -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 VAA23236 for ; Tue, 24 Feb 2004 21:51:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avp8x-0007OF-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 21:51:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avp7u-0007Ji-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 21:50:23 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1Avp7C-0007CU-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 21:49:38 -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 <0HTM00F01BV1SA@endeavor.poss.com> for dhcwg@ietf.org; Tue, 24 Feb 2004 21:49:03 -0500 (EST) Received: from kan1 (pat-vpn1.pahousegop.com [192.216.120.27]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HTM00G1HD5PCW@endeavor.poss.com> for dhcwg@ietf.org; Tue, 24 Feb 2004 21:49:02 -0500 (EST) Date: Tue, 24 Feb 2004 21:49:30 -0500 From: "Kevin A. Noll" In-reply-to: <005b01c3fb3e$0c6314f0$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] DHCPINFORM Implementations? 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 anyone point me to an OS or application that actually uses DHCPINFORM? --kan-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 24 22:20:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24082; Tue, 24 Feb 2004 22:20: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 1Avpad-0004bw-RU; Tue, 24 Feb 2004 22: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 1Avpa5-0004ag-GX for dhcwg@optimus.ietf.org; Tue, 24 Feb 2004 22:19: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 WAA24038 for ; Tue, 24 Feb 2004 22:19:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avpa2-0001m3-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 22:19:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvpZ4-0001i5-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 22:18:27 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1AvpYh-0001e1-00 for dhcwg@ietf.org; Tue, 24 Feb 2004 22:18:03 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.36 #1 (Debian)) id 1AvpYB-0008QW-00; Tue, 24 Feb 2004 19:17:31 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id <18G0JTZ3>; Tue, 24 Feb 2004 19:17:26 -0800 Message-ID: From: "Kostur, Andre" To: "'Kevin A. Noll'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHCPINFORM Implementations? Date: Tue, 24 Feb 2004 19:17:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FB4D.E2B3BEB0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,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_01C3FB4D.E2B3BEB0 Content-Type: text/plain; charset="iso-8859-1" If I recall correctly, MSDHCP servers use it to find other servers, and I believe one of our customers has a Novell client for windows that uses DHCPINFORM to get the novell options. > -----Original Message----- > From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] > Sent: Tuesday, February 24, 2004 6:50 PM > To: dhcwg@ietf.org > Subject: [dhcwg] DHCPINFORM Implementations? > > > > Can anyone point me to an OS or application that actually > uses DHCPINFORM? > > --kan-- > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C3FB4D.E2B3BEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCPINFORM Implementations?

If I recall correctly, MSDHCP servers use it to find = other servers, and I believe one of our customers has a Novell client = for windows that uses DHCPINFORM to get the novell options.

> -----Original Message-----
> From: Kevin A. Noll [mailto:kevin.noll@perfectord= er.com]
> Sent: Tuesday, February 24, 2004 6:50 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] DHCPINFORM = Implementations?
>
>
>
> Can anyone point me to an OS or application = that actually
> uses DHCPINFORM?
>
> --kan--
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C3FB4D.E2B3BEB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 25 01:24:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00008; Wed, 25 Feb 2004 01:24: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 1AvsSe-0007jN-La; Wed, 25 Feb 2004 01:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsSA-0007i9-67 for dhcwg@optimus.ietf.org; Wed, 25 Feb 2004 01:23:30 -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 BAA29969 for ; Wed, 25 Feb 2004 01:23:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsS6-0001zq-00 for dhcwg@ietf.org; Wed, 25 Feb 2004 01:23:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsRB-0001vc-00 for dhcwg@ietf.org; Wed, 25 Feb 2004 01:22:30 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AvsQF-0001o0-00 for dhcwg@ietf.org; Wed, 25 Feb 2004 01:21:32 -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 <0HTM00M14MXGPE@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 15:20: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 <0HTM00ACYMWOIW@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 15:19:36 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTM004YZMWO6P@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 25 Feb 2004 15:19:36 +0900 (KST) Date: Wed, 25 Feb 2004 15:19:38 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] daniel-dhc-ipv6in4-opt comments In-reply-to: <005b01c3fb3e$0c6314f0$6401a8c0@BVolz> To: "'Bernie Volz'" Cc: kimps@samsung.com, "'Ralph Droms'" , dhcwg@ietf.org Message-id: <009c01c3fb67$58cd5200$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 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 > Not sure exactly what you mean, but yes for each configured > tunnel endpoint > you need three items (a tuple): > - IPv4 address of the tunnel endpoint (4-bytes) > - IPv6 prefix length for the IPv6 route to the tunnel endpoint > (1-byte) > - IPv6 prefix for the route ... (prefix length/8 bytes) > When the prefix length is 0, no prefix is needed (since it is > 0). You can put them in any order you like, but to compress the > information, you'll need to put the prefix length before the prefix. Yes, that's my assumption ! > Are the prefix length and prefix really needed? Will routing > information (RAs) arrive over the tunnel that might already > supply this (and thus avoid the need for configuration through > DHCPv4)? If multiple tunnels exist, one could assume they are > like IPv4 default routes and the routing information > should eventually get sorted out such that the proper tunnel is used? > (Ralph's comment regarding the DHCPv6 tunneling option draft > made we wonder about this issue here as well.) I will let you know on that in the next response. It should be deeply considered on both drafts of course. 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 Wed Feb 25 10:48:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23266; Wed, 25 Feb 2004 10:48: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 1Aw1GS-0003IE-MJ; Wed, 25 Feb 2004 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1Fa-00032q-BS for dhcwg@optimus.ietf.org; Wed, 25 Feb 2004 10:47:06 -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 KAA23154 for ; Wed, 25 Feb 2004 10:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1FX-00060M-00 for dhcwg@ietf.org; Wed, 25 Feb 2004 10:47:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1Ef-0005uc-00 for dhcwg@ietf.org; Wed, 25 Feb 2004 10:46:09 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1EG-0005ne-00 for dhcwg@ietf.org; Wed, 25 Feb 2004 10:45:44 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2004 07:48:00 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1PFjC0K029059 for ; Wed, 25 Feb 2004 10:45:12 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-77.cisco.com [10.86.240.77]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGH68700; Wed, 25 Feb 2004 10:45:11 -0500 (EST) Message-Id: <4.3.2.7.2.20040225104345.01fd9ac0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Feb 2004 10:45:09 -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.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Subject: [dhcwg] Scribes and Jabber scribe for dhc WG meeting in Seoul (2nd try) 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: , Let me know if you're willing to volunteer to act as scribe for the WG meeting in Seoul. (Ted Lemon has volunteered to act as meeting scribe; I'd like to identify a second volunteer to ensure complete notes) The dhc WG meeting is scheduled for Tue, 3/2, 0900-1130 (Seoul). If I have my conversions correct, that time is equivalent to: 3/2 0530 IST 3/2 0000 UTC 3/1 1900 EST 3/1 1600 PST I plan to make a Jabber session available, so let me know if you're interested in joining the Jabber session. If you will attend the meeting in person, let me know if you're willing to act as a Jabber scribe. (I've heard from Barr Hibbs that he intends to participate remotely in the Jabber session. Anyone else?) Thanks... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 27 08:35:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00463; Fri, 27 Feb 2004 08:35: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 1Awi8t-00028p-6o; Fri, 27 Feb 2004 08:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awi8A-00027p-5r for dhcwg@optimus.ietf.org; Fri, 27 Feb 2004 08:34: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 IAA00406 for ; Fri, 27 Feb 2004 08:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awi88-0004XZ-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 08:34:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awi7B-0004SG-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 08:33:18 -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 1Awi6L-0004Ik-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 08:32:25 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2004 05:43:17 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1RDVr1m014433 for ; Fri, 27 Feb 2004 05:31:53 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-33.cisco.com [10.86.240.33]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGJ25599; Fri, 27 Feb 2004 08:31:52 -0500 (EST) Message-Id: <4.3.2.7.2.20040227083040.01faa0e0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Feb 2004 08:31:49 -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.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Subject: [dhcwg] Scribes and Jabber scribe for dhc WG meeting in Seoul (3rd try) 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: , Let me know if you're willing to volunteer to act as scribe for the WG meeting in Seoul. (Ted Lemon has volunteered to act as meeting scribe; I'd like to identify a second volunteer to ensure complete notes) The dhc WG meeting is scheduled for Tue, 3/2, 0900-1130 (Seoul). If I have my conversions correct, that time is equivalent to: 3/2 0530 IST 3/2 0000 UTC 3/1 1900 EST 3/1 1600 PST I plan to make a Jabber session available, so let me know if you're interested in joining the Jabber session. The jabber session for the dhcwg is available at dhc@ietf.xmpp.org. If you will attend the meeting in person, let me know if you're willing to act as a Jabber scribe. (I've heard from Barr Hibbs that he intends to participate remotely in the Jabber session. Anyone else?) Thanks... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 27 09:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02588; Fri, 27 Feb 2004 09:12: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 1Awiie-0005OI-Fa; Fri, 27 Feb 2004 09:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awii4-0005MS-KP for dhcwg@optimus.ietf.org; Fri, 27 Feb 2004 09:11:24 -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 JAA02558 for ; Fri, 27 Feb 2004 09:11:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awii3-0001JY-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 09:11:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awih7-0001Dy-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 09:10:25 -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 1Awigc-00018T-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 09:09:54 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1RE9M4U017382 for ; Fri, 27 Feb 2004 06:09:22 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-33.cisco.com [10.86.240.33]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGJ27767; Fri, 27 Feb 2004 09:09:21 -0500 (EST) Message-Id: <4.3.2.7.2.20040227090834.02a41268@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Feb 2004 09:09:19 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: [dhcwg] Scribes and Jabber scribe for dhc WG meeting in Seoul (3rd try) 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.0 required=5.0 tests=AWL 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: , FYI - the dhc WG Jabber session at dhc@ietf.xmpp.org is available now, if you want to test it to confirm your connectivity before the WG meeting. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 27 11:42:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12591; Fri, 27 Feb 2004 11:42: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 1Awl3p-0004Qh-Re; Fri, 27 Feb 2004 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awl3G-0004PP-Jn for dhcwg@optimus.ietf.org; Fri, 27 Feb 2004 11:41:26 -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 LAA12559 for ; Fri, 27 Feb 2004 11:41:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awl3F-0005GW-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 11:41:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awl2H-0005Bp-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 11:40:25 -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 1Awl1h-00053E-00 for dhcwg@ietf.org; Fri, 27 Feb 2004 11:39:49 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2004 08:50:01 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1RGdHuA013514 for ; Fri, 27 Feb 2004 08:39:17 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGJ41052; Fri, 27 Feb 2004 11:39:16 -0500 (EST) Message-Id: <4.3.2.7.2.20040227113616.01f2b008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Feb 2004 11:39:14 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] dhc WG meeting speakers 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: , For those who are speaking at the dhc WG meeting in Seoul - we have a *very* tight schedule, so I'll need to keep everyone to the assigned time slots. If at all possible, please send me any slides you want to use at the meeting so I can have them ready for presentation from my laptop to avoid delays from switching displays. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 29 10:18:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26548; Sun, 29 Feb 2004 10:18: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 1AxShc-0000UO-Qs; Sun, 29 Feb 2004 10: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 1AxShY-0000T9-BU for dhcwg@optimus.ietf.org; Sun, 29 Feb 2004 10:17: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 KAA26494 for ; Sun, 29 Feb 2004 10:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxShW-0005j0-00 for dhcwg@ietf.org; Sun, 29 Feb 2004 10:17:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxSgX-0005dq-00 for dhcwg@ietf.org; Sun, 29 Feb 2004 10:16:54 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AxSfa-0005Yt-00 for dhcwg@ietf.org; Sun, 29 Feb 2004 10:15:54 -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 i1TFFj57089065 for ; Sun, 29 Feb 2004 10:15:53 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: Date: Sun, 29 Feb 2004 10:15:48 -0500 Message-ID: <000501c3fed6$ec341ac0$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C3FEAD.035E12C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 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.1 required=5.0 tests=AWL,HTML_70_80,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] draft-ietf-dhc-vendor-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: , This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C3FEAD.035E12C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Regarding draft-ietf-dhc-vendor-01.txt, how do people feel about the suggestion of using ONE option to carry both options, using the following format? 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | class-len | | +-+-+-+-+-+-+-+-+ class-data | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subopt-len | | +-+-+-+-+-+-+-+-+ subopt-data | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Of course, one or both class-len and subopt-len could be 0. In general, a client may send the option with a class and possibly suboptions and a server would generally just send suboptions (unless we felt it best to have the server echo back the class information). The advantages are: - Only a single DHCPv4 option is used (not two). - The enterprise-number needs only to appear once (not twice) if both the class and information options are needed. - Bernie ------=_NextPart_000_0006_01C3FEAD.035E12C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding = draft-ietf-dhc-vendor-01.txt, how do people feel about the

suggestion of using = ONE option to carry both options, using the

following = format?

 

           &= nbsp;            1 1 1 1 1 1

    = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |  option-code  |  option-len   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |       = enterprise-number       |

   |            =             &= nbsp;      |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |   class-len   |            =    |

   +-+-+-+-+-+-+-+-+   class-data  |

   /            =             &= nbsp;      /

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |  subopt-len   |            =    |

   +-+-+-+-+-+-+-+-+  subopt-data  |

   /            =             &= nbsp;      /

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Of course, one or = both class-len and subopt-len could be 0.

 

In general, a client may send the option with = a class and possibly

suboptions and a server would generally just = send suboptions (unless

we felt it best to have the server echo back = the class information).

 

The advantages are:

- Only a single DHCPv4 option is used (not = two).

- The enterprise-number needs only to appear = once (not twice) if both

the class and information options are = needed.

 

- Bernie

 

------=_NextPart_000_0006_01C3FEAD.035E12C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg