From dhcwg-admin@ietf.org Thu Jan 1 18:36:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27051; Thu, 1 Jan 2004 18:36: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 1AcCMF-0005vZ-Em; Thu, 01 Jan 2004 18:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbxMs-0004tA-Fb for dhcwg@optimus.ietf.org; Thu, 01 Jan 2004 02:35: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 CAA23581 for ; Thu, 1 Jan 2004 02:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbxMo-0006RB-00 for dhcwg@ietf.org; Thu, 01 Jan 2004 02:35:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbxLC-0006PI-00 for dhcwg@ietf.org; Thu, 01 Jan 2004 02:34:01 -0500 Received: from fep04-svc.mail.telepac.pt ([194.65.5.203]) by ietf-mx with esmtp (Exim 4.12) id 1AbxJc-0006NV-00 for dhcwg@ietf.org; Thu, 01 Jan 2004 02:32:20 -0500 Received: from thunder ([81.193.119.213]) by fep04-svc.mail.telepac.pt (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with SMTP id <20040101073150.OKSQ26031.fep04-svc.mail.telepac.pt@thunder> for ; Thu, 1 Jan 2004 07:31:50 +0000 Message-ID: <000501c3d039$534fae30$fc03a8c0@thunder> Reply-To: "Pedro Borges" From: "Pedro Borges" To: Date: Thu, 1 Jan 2004 07:31:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP timezone Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.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 just had an idea, and perhaps I'm adding to an already existing feature, but it stuck me as natural for a dhcp server to notify host computers of the local timezone, so one can have his host computer sync with any timeserver and still have accurate local time when connecting through dhcp services throughout the world. Like I said please disregard this if it's an already existing feature (yeah I didn't bother to check) Cheers, Pedro Borges _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 1 18:58:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27725; Thu, 1 Jan 2004 18:58: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 1AcChV-0006mo-BD; Thu, 01 Jan 2004 18: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 1AcChM-0006mV-OL for dhcwg@optimus.ietf.org; Thu, 01 Jan 2004 18:57: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 SAA27704 for ; Thu, 1 Jan 2004 18:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcChJ-0002kg-00 for dhcwg@ietf.org; Thu, 01 Jan 2004 18:57:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcCfj-0002hF-00 for dhcwg@ietf.org; Thu, 01 Jan 2004 18:56:14 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1AcCej-0002Zs-00 for dhcwg@ietf.org; Thu, 01 Jan 2004 18:55:09 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AcCeD-0003cS-00; Thu, 01 Jan 2004 15:54:37 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jan 2004 15:54:32 -0800 Message-ID: From: "Kostur, Andre" To: "'Pedro Borges'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHCP timezone Date: Thu, 1 Jan 2004 15:54:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D0C2.95EE4880" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.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_01C3D0C2.95EE4880 Content-Type: text/plain; charset="iso-8859-1" See RFC 2132, Option 2 (and 4). > -----Original Message----- > From: Pedro Borges [mailto:mrpcb@netcabo.pt] > Sent: Wednesday, December 31, 2003 11:32 PM > To: dhcwg@ietf.org > Subject: [dhcwg] DHCP timezone > > > I just had an idea, and perhaps I'm adding to an already > existing feature, > but it stuck me as natural for a dhcp server to notify host > computers of the > local timezone, so one can have his host computer sync with > any timeserver > and still have accurate local time when connecting through > dhcp services > throughout the world. > Like I said please disregard this if it's an already existing > feature (yeah > I didn't bother to check) > > Cheers, > Pedro Borges > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C3D0C2.95EE4880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP timezone

See RFC 2132, Option 2 (and 4).

> -----Original Message-----
> From: Pedro Borges [mailto:mrpcb@netcabo.pt]
> Sent: Wednesday, December 31, 2003 11:32 = PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] DHCP timezone
>
>
> I just had an idea, and perhaps I'm adding to = an already
> existing feature,
> but it stuck me as natural for a dhcp server to = notify host
> computers of the
> local timezone, so one can have his host = computer sync with
> any timeserver
> and still have accurate local time when = connecting through
> dhcp services
> throughout the world.
> Like I said please disregard this if it's an = already existing
> feature (yeah
> I didn't bother to check)
>
> Cheers,
> Pedro Borges
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C3D0C2.95EE4880-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 1 19:24:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27050; Thu, 1 Jan 2004 18:36: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 1AcCME-0005vB-Ck; Thu, 01 Jan 2004 18: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 1Abkvk-0007LJ-Ms for dhcwg@optimus.ietf.org; Wed, 31 Dec 2003 13:18: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 NAA19888 for ; Wed, 31 Dec 2003 13:18:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbkvY-0006qP-00 for dhcwg@ietf.org; Wed, 31 Dec 2003 13:18:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Abks1-0006nE-00 for dhcwg@ietf.org; Wed, 31 Dec 2003 13:15:01 -0500 Received: from mail-in-02.arcor-online.net ([151.189.21.42]) by ietf-mx with esmtp (Exim 4.12) id 1Abkpf-0006jX-00 for dhcwg@ietf.org; Wed, 31 Dec 2003 13:12:35 -0500 Received: from t4j6f1 (dialin-145-254-255-037.arcor-ip.net [145.254.255.37]) by mail-in-02.arcor-online.net (Postfix) with SMTP id 10F015DA450 for ; Wed, 31 Dec 2003 19:11:59 +0100 (CET) Received: by localhost with Microsoft MAPI; Wed, 31 Dec 2003 19:13:59 +0100 Message-ID: <01C3CFD2.3E7F0760.mrentsch@arcor.de> From: Markus Rentschler Reply-To: "mrentsch@arcor.de" To: "'dhcwg@ietf.org'" Subject: AW: [dhcwg] Accept as WG work item? Date: Wed, 31 Dec 2003 19:01:21 +0100 X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 Encoding: 71 TEXT 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: , In our field the TFTP-Server/Bootfile options are not used for diskless booting, but rather to transfer a specific configuration file to a specific client. For redundancy it makes sense to be able to tell the client an alternative source of this information. I regard the option described in this draft therefore as useful and my opinion is that it should be adopted as a work group item. -Markus -----Ursprungliche Nachricht----- Von: Ralph Droms [SMTP:rdroms@cisco.com] Gesendet am: Montag, 29. Dezember 2003 14:37 An: dhcwg@ietf.org Betreff: [dhcwg] Accept as WG work item? > ---------- > From: Ralph Droms[SMTP:RDROMS@CISCO.COM] > Sent: Monday, December 29, 2003 2:37:25 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Accept as WG work item? > Auto forwarded by a Rule > We have a request to accept draft-vijay-dhc-opt-extrboot-00.txt as a WG action item. Here is the Abstract and the Introduction: Abstract Single TFTP server for huge number of diskless clients is prone to single point of failure. So, Multiple TFTP servers are needed for high availability. Moreover, some of the clients need multiple bootfiles for boot up. This document provides a new DHCPv4 option for clients to obtain information about multiple TFTP servers and bootfiles. 1. Introduction DHCPv4 (Dynamic Host Configuration Protocol Version for IPv4) provides a framework for passing configuration information to hosts on an IPv4 network. However, DHCPv4 does not provide a way to send more than one TFTP server address and bootfile names. This document defines a new option to provide more than one TFTP server and bootfile names. This option is required for clients, which are booting over a network and require more than one file to be downloaded and executed. The multiple TFTP servers are needed for high availability. Network booting is widely used mechanism for booting up of the clients, because of their advantages; softwares will be in central server and requires maintenance at only one location rather than maintaining individual systems separately. Also, switching between different operating systems becomes easy when network booting is being used. The additional boot files may be used as supporting software for the boot image. Different Operating System vendors use different way of handling this. Please respond to dhcwg@ietf.org by 1/6/2004 with comments about this I-D and whether the dhc WG should accept this I-D as a WG work item. If there are no objections, the default action will be for the dhc WG to accept the I-D as a WG work item. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 2 11:04:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13931; Fri, 2 Jan 2004 11:04: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 1AcRmL-0005Ig-Bv; Fri, 02 Jan 2004 11: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 1AcRmA-0005IV-LA for dhcwg@optimus.ietf.org; Fri, 02 Jan 2004 11:03: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 LAA13916 for ; Fri, 2 Jan 2004 11:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcRm3-0006q5-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 11:03:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcRjS-0006mj-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 11:01:05 -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 1AcRhA-0006jJ-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 10:58:40 -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 i02Fw7VM009352 for ; Fri, 2 Jan 2004 07:58:08 -0800 (PST) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-195.cisco.com [10.21.96.195]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEZ18704; Fri, 2 Jan 2004 10:58:06 -0500 (EST) Message-Id: <4.3.2.7.2.20040102104312.01e3c220@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jan 2004 10:58:04 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG is reviewing draft-ietf-dhc-dhcpv6-stateless-03.txt, "A Guide to Implementing Stateless DHCPv6 Service". There is a request to change the title to simply "Stateless DHCPv6 Service", because the document defines a subset of RFC 3315, rather than giving a guide to implementing RFC 3315. I am concerned that there has been confusion in the past that draft-ietf-dhc-dhcpv6-stateless-03.txt is simply a reference into RFC 3315, and that draft-ietf-dhc-dhcpv6-stateless-03.txt does *not* describe a new protocol. If the WG is confident that the change won't add to the potential for confusion and there are no other objections, I'll change the title of draft-ietf-dhc-dhcpv6-stateless-03.txt to "Stateless DHCPv6 Service" - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 2 11:31:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14791; Fri, 2 Jan 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 1AcSCU-0006If-9y; Fri, 02 Jan 2004 11: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 1AcSC6-0006Hq-Iz for dhcwg@optimus.ietf.org; Fri, 02 Jan 2004 11:30:38 -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 LAA14755 for ; Fri, 2 Jan 2004 11:30:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcSC5-0000FC-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 11:30:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcSAS-000088-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 11:28:59 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AcS8K-0007lW-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 11:26:44 -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 091D11B200E; Fri, 2 Jan 2004 10:22:17 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040102104312.01e3c220@flask.cisco.com> References: <4.3.2.7.2.20040102104312.01e3c220@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <72EF0E77-3D40-11D8-A3FF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Date: Fri, 2 Jan 2004 10:26:42 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.609) 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 it's fine to change the name. The fact that it's referencing DHCPv6 in the title seems sufficient to eliminate confusion, and if anyone remains confused, they will realize they need RFC3315 when they read the document. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 2 11:55:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15510; Fri, 2 Jan 2004 11: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 1AcSZi-00079x-Pa; Fri, 02 Jan 2004 11: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 1AcSYk-00079G-Vg for dhcwg@optimus.ietf.org; Fri, 02 Jan 2004 11:54: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 LAA15454 for ; Fri, 2 Jan 2004 11:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcSYj-0001Db-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 11:54:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcSWn-00018b-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 11:52:04 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AcSUr-00011S-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 11:50:01 -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 i02GnmGn095230; Fri, 2 Jan 2004 11:49:57 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Date: Fri, 2 Jan 2004 11:49:59 -0500 Message-ID: <000001c3d150$7881fec0$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.20040102104312.01e3c220@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ralph: I don't have any objection to changing the document name to "Stateless DHCPv6 Server".=20 I would suggest that perhaps section 4 have an explicit reference to RFC 3315 and DHCPv6: 4. Basic Requirements for Implementation of DHCP Several sections of the DHCPv6 specification [1] provide = background ^^ ^^^ information or define parts of the specification that are common to all implementations: Note that in most places you refer to RFC 3315 as "DHCPv6 specification" = and not DHCP specification. Also, you should review your use of DHCP vs. DHCPv6 throughout. In = section 2, you state "Throughout this document, "DHCP" refers to DHCP for IPv6." = But DHCPv6 is used fairly frequently. Personally, I'd prefer that "DHCPv6" = be used instead of just "DHCP". But, whichever you decide, I think it = important that the usage is consistent. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Friday, January 02, 2004 10:58 AM To: dhcwg@ietf.org Subject: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt The IESG is reviewing draft-ietf-dhc-dhcpv6-stateless-03.txt, "A Guide = to Implementing Stateless DHCPv6 Service". There is a request to change = the title to simply "Stateless DHCPv6 Service", because the document defines = a subset of RFC 3315, rather than giving a guide to implementing RFC 3315. I am concerned that there has been confusion in the past that draft-ietf-dhc-dhcpv6-stateless-03.txt is simply a reference into RFC = 3315, and that draft-ietf-dhc-dhcpv6-stateless-03.txt does *not* describe a = new protocol. If the WG is confident that the change won't add to the = potential for confusion and there are no other objections, I'll change the title = of draft-ietf-dhc-dhcpv6-stateless-03.txt to "Stateless DHCPv6 Service" - 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 Jan 2 12:57:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16915; Fri, 2 Jan 2004 12:57: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 1AcTXh-0000yA-5R; Fri, 02 Jan 2004 12: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 1AcTWn-0000x2-K2 for dhcwg@optimus.ietf.org; Fri, 02 Jan 2004 12:56: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 MAA16899 for ; Fri, 2 Jan 2004 12:56:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcTWl-0003bN-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 12:56:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcTUw-0003XB-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 12:54:13 -0500 Received: from smtp107.mail.sc5.yahoo.com ([66.163.169.227]) by ietf-mx with smtp (Exim 4.12) id 1AcTTA-0003SY-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 12:52:20 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.88.188 with login) by smtp107.mail.sc5.yahoo.com with SMTP; 2 Jan 2004 17:52:18 -0000 Reply-To: From: "Barr Hibbs" To: "Kevin A. Noll" , Subject: RE: [dhcwg] Valid states for use of DHCPRELEASE? Date: Fri, 2 Jan 2004 09:54:49 -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: Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit yes, of course, but it is not a very interesting state: once the client transitions to the STOPPED state, nothing else will happen. The intended behavior of a DHCP client was for it to be persistent because it was expected to request (and be offered) a lease with a limited lifetime that would be periodically renewed by the client. That mechanism ceases to function if the client goes to a STOPPED state. --Barr > -----Original Message----- > From: Kevin A. Noll > Sent: Tuesday, December 30, 2003 20:23 > To: dhcwg@ietf.org > > Could I also claim that an additional state could be > added to the client state machine (call it "STOPPED") that > the client transitions to after sending a DHCPRELEASE? > > The assumption would be that the STOPPED state would be > associated with a graceful shutdown of the system or with > some external process that caused the client to RELEASE. If > this is the case, then STOPPED would be a final state (like > INIT or INIT-REBOOT are the beginning states). > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 2 13:24:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17478; Fri, 2 Jan 2004 13:24: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 1AcTxo-0001m6-Vr; Fri, 02 Jan 2004 13: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 1AcTxS-0001lh-Nd for dhcwg@optimus.ietf.org; Fri, 02 Jan 2004 13:23:38 -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 NAA17463 for ; Fri, 2 Jan 2004 13:23:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcTxL-0004RJ-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 13:23:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcTug-0004M7-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 13:20:49 -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 1AcTrB-0004F4-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 13:17:09 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Jan 2004 10:22:52 +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 i02IG8VM001835; Fri, 2 Jan 2004 10:16:08 -0800 (PST) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-195.cisco.com [10.21.96.195]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEZ24519; Fri, 2 Jan 2004 13:16:06 -0500 (EST) Message-Id: <4.3.2.7.2.20040102130600.01e658f0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jan 2004 13:16:03 -0500 To: "Bernie Volz" From: Ralph Droms Subject: RE: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Cc: In-Reply-To: <000001c3d150$7881fec0$6401a8c0@BVolz> References: <4.3.2.7.2.20040102104312.01e3c220@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bernie - just for clarity, I'm guessing "Stateless DHCPv6 Service" (and your "Server" was a typo) is OK with you. I must admit the use of "DHCPv6 specification" throughout the doc is a legacy from originally writing the doc prior to the publication of RFC 3315. I'll just use RFC 3315 throughout. Regarding DHCPv6 vs. DHCP - I looked back and found we weren't consistent in RFC 3315, using mostly DHCP but also using DHCPv6 on a few (apparently random) occasions. Either DHCP or DHCPv6 would be OK with me. Anyone else have a preference? I'll be sure the doc is consistent, whichever term we decide to use. - Ralph At 11:49 AM 1/2/2004 -0500, Bernie Volz wrote: >Ralph: > >I don't have any objection to changing the document name to "Stateless >DHCPv6 Server". > >I would suggest that perhaps section 4 have an explicit reference to RFC >3315 and DHCPv6: > >4. Basic Requirements for Implementation of DHCP > > Several sections of the DHCPv6 specification [1] provide background > ^^ ^^^ > information or define parts of the specification that are common > to all implementations: > >Note that in most places you refer to RFC 3315 as "DHCPv6 specification" and >not DHCP specification. > >Also, you should review your use of DHCP vs. DHCPv6 throughout. In section >2, you state "Throughout this document, "DHCP" refers to DHCP for IPv6." But >DHCPv6 is used fairly frequently. Personally, I'd prefer that "DHCPv6" be >used instead of just "DHCP". But, whichever you decide, I think it important >that the usage is consistent. > >- Bernie > > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph >Droms >Sent: Friday, January 02, 2004 10:58 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt > >The IESG is reviewing draft-ietf-dhc-dhcpv6-stateless-03.txt, "A Guide to >Implementing Stateless DHCPv6 Service". There is a request to change the >title to simply "Stateless DHCPv6 Service", because the document defines a >subset of RFC 3315, rather than giving a guide to implementing RFC 3315. > >I am concerned that there has been confusion in the past that >draft-ietf-dhc-dhcpv6-stateless-03.txt is simply a reference into RFC 3315, >and that draft-ietf-dhc-dhcpv6-stateless-03.txt does *not* describe a new >protocol. If the WG is confident that the change won't add to the potential >for confusion and there are no other objections, I'll change the title of >draft-ietf-dhc-dhcpv6-stateless-03.txt to "Stateless DHCPv6 Service" > >- 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 Jan 2 13:31:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17767; Fri, 2 Jan 2004 13:31: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 1AcU4c-0001yy-Or; Fri, 02 Jan 2004 13: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 1AcU4B-0001xh-2f for dhcwg@optimus.ietf.org; Fri, 02 Jan 2004 13:30: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 NAA17742 for ; Fri, 2 Jan 2004 13:30:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcU49-0004n0-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 13:30:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcU2P-0004hm-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 13:28:48 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AcU0w-0004bY-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 13:27:14 -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 i02IQu57086021; Fri, 2 Jan 2004 13:27:04 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" Cc: Subject: RE: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Date: Fri, 2 Jan 2004 13:27:06 -0500 Message-ID: <000001c3d15e$09cd3400$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: <4.3.2.7.2.20040102130600.01e658f0@flask.cisco.com> Importance: Normal 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 Yes, server was a typo. Using RFC 3315 would be fine. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Friday, January 02, 2004 1:16 PM To: Bernie Volz Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Bernie - just for clarity, I'm guessing "Stateless DHCPv6 Service" (and=20 your "Server" was a typo) is OK with you. I must admit the use of "DHCPv6 specification" throughout the doc is a=20 legacy from originally writing the doc prior to the publication of RFC=20 3315. I'll just use RFC 3315 throughout. Regarding DHCPv6 vs. DHCP - I looked back and found we weren't = consistent=20 in RFC 3315, using mostly DHCP but also using DHCPv6 on a few = (apparently=20 random) occasions. Either DHCP or DHCPv6 would be OK with me. Anyone = else have a preference? I'll be sure the doc is consistent, whichever = term=20 we decide to use. - Ralph At 11:49 AM 1/2/2004 -0500, Bernie Volz wrote: >Ralph: > >I don't have any objection to changing the document name to "Stateless >DHCPv6 Server". > >I would suggest that perhaps section 4 have an explicit reference to = RFC >3315 and DHCPv6: > >4. Basic Requirements for Implementation of DHCP > > Several sections of the DHCPv6 specification [1] provide = background > ^^ ^^^ > information or define parts of the specification that are common > to all implementations: > >Note that in most places you refer to RFC 3315 as "DHCPv6 = specification" and >not DHCP specification. > >Also, you should review your use of DHCP vs. DHCPv6 throughout. In = section >2, you state "Throughout this document, "DHCP" refers to DHCP for = IPv6." But >DHCPv6 is used fairly frequently. Personally, I'd prefer that "DHCPv6" = be >used instead of just "DHCP". But, whichever you decide, I think it important >that the usage is consistent. > >- Bernie > > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph >Droms >Sent: Friday, January 02, 2004 10:58 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt > >The IESG is reviewing draft-ietf-dhc-dhcpv6-stateless-03.txt, "A Guide = to >Implementing Stateless DHCPv6 Service". There is a request to change = the >title to simply "Stateless DHCPv6 Service", because the document = defines a >subset of RFC 3315, rather than giving a guide to implementing RFC = 3315. > >I am concerned that there has been confusion in the past that >draft-ietf-dhc-dhcpv6-stateless-03.txt is simply a reference into RFC = 3315, >and that draft-ietf-dhc-dhcpv6-stateless-03.txt does *not* describe a = new >protocol. If the WG is confident that the change won't add to the potential >for confusion and there are no other objections, I'll change the title = of >draft-ietf-dhc-dhcpv6-stateless-03.txt to "Stateless DHCPv6 Service" > >- 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 Jan 2 15:23:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22930; Fri, 2 Jan 2004 15:23: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 1AcVoz-0005fo-0C; Fri, 02 Jan 2004 15: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 1AcVo6-0005dW-TV for dhcwg@optimus.ietf.org; Fri, 02 Jan 2004 15: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 PAA22891 for ; Fri, 2 Jan 2004 15:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcVnv-0002NC-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 15:21:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcVhx-00029d-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 15:15:48 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AcVci-0001sB-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 15:10:20 -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 D09FA1B200E; Fri, 2 Jan 2004 14:05:27 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , "Kevin A. Noll" From: Ted Lemon Subject: Re: [dhcwg] Valid states for use of DHCPRELEASE? Date: Fri, 2 Jan 2004 14:09:55 -0600 To: X-Mailer: Apple Mail (2.609) 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 Jan 2, 2004, at 11:54 AM, Barr Hibbs wrote: > yes, of course, but it is not a very interesting state: once the > client > transitions to the STOPPED state, nothing else will happen. Until something changes. You don't leave the STOPPED state without the system's or user's intervention, but that's not to say that you never leave that state. In any case, it's an interesting state if only in the sense that every client I've ever used supports it, even though it's never documented in RFC2131. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 2 18:31:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29591; Fri, 2 Jan 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 1AcYkv-0002nK-Qx; Fri, 02 Jan 2004 18: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 1AcYk8-0002mc-K7 for dhcwg@optimus.ietf.org; Fri, 02 Jan 2004 18:30: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 SAA29585 for ; Fri, 2 Jan 2004 18:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcYk5-0003Ip-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 18:30:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcYiC-0003Gj-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 18:28:13 -0500 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1AcYhB-0003EH-00 for dhcwg@ietf.org; Fri, 02 Jan 2004 18:27:10 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2BA8D111E1; Fri, 2 Jan 2004 18:27:10 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jan 2004 18:27:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Date: Fri, 2 Jan 2004 18:27:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05836729@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Thread-Index: AcPRShYjHwdid+gETD6a2M0JU7IpxwAPc67A From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 02 Jan 2004 23:27:09.0858 (UTC) FILETIME=[F179B020:01C3D187] 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 This sounds like correct title to me Ralph per IESG. /jim > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of Ralph Droms > Sent: Friday, January 02, 2004 10:58 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt >=20 >=20 > The IESG is reviewing draft-ietf-dhc-dhcpv6-stateless-03.txt,=20 > "A Guide to > Implementing Stateless DHCPv6 Service". There is a request=20 > to change the > title to simply "Stateless DHCPv6 Service", because the=20 > document defines a > subset of RFC 3315, rather than giving a guide to=20 > implementing RFC 3315. >=20 > I am concerned that there has been confusion in the past that > draft-ietf-dhc-dhcpv6-stateless-03.txt is simply a reference=20 > into RFC 3315, > and that draft-ietf-dhc-dhcpv6-stateless-03.txt does *not*=20 > describe a new > protocol. If the WG is confident that the change won't add=20 > to the potential > for confusion and there are no other objections, I'll change=20 > the title of > draft-ietf-dhc-dhcpv6-stateless-03.txt to "Stateless DHCPv6 Service" >=20 > - Ralph >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 3 18:29:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17514; Sat, 3 Jan 2004 18: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 1AcvCX-0003KB-0d; Sat, 03 Jan 2004 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcvC7-0003Jc-QC for dhcwg@optimus.ietf.org; Sat, 03 Jan 2004 18:28: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 SAA17501 for ; Sat, 3 Jan 2004 18:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcvC4-0000MM-00 for dhcwg@ietf.org; Sat, 03 Jan 2004 18:28:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcvAB-0000Jq-00 for dhcwg@ietf.org; Sat, 03 Jan 2004 18:26:36 -0500 Received: from smtp016.mail.yahoo.com ([216.136.174.113]) by ietf-mx with smtp (Exim 4.12) id 1Acv8V-0000HG-00 for dhcwg@ietf.org; Sat, 03 Jan 2004 18:24:52 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.88.188 with login) by smtp016.mail.yahoo.com with SMTP; 3 Jan 2004 23:24:51 -0000 Reply-To: From: "Barr Hibbs" To: "Ralph Droms" , Subject: RE: [dhcwg] New drafts as WG work items? Date: Sat, 3 Jan 2004 15:27:25 -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.20031229075610.01ead5f8@flask.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.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-- would you add this draft to the list for consideration as a WG item? --Barr A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Proposed Changes to the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Author(s) : R. Hibbs Filename : draft-hibbs-dhc-changes-00.txt Pages : 7 Date : 2003-12-4 This memo describes the requirements of Internet-Drafts proposing changes to the Dynamic Host Configuration Protocol for IPv4 (DHCPv4). These requirements specifically cover documentation expected whenever message formats or client state transitions are modified. > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Monday, December 29, 2003 05:11 > To: dhcwg@ietf.org > Subject: [dhcwg] New drafts as WG work items? > > > At the WG meeting in Minneapolis, I mentioned six I-Ds that we need to > review for acceptance as dhc WG work items. Here is a list of the latest > revisions of those I-Ds: > > > > > > > > > I will start an e-mail thread for comments about each of these > I-Ds. Please > respond with comments by 1/6/3004. > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 4 20:24:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14935; Sun, 4 Jan 2004 20:24: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 1AdJTN-0008F4-Fx; Sun, 04 Jan 2004 20: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 1AdJSf-0008EZ-UM for dhcwg@optimus.ietf.org; Sun, 04 Jan 2004 20:23: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 UAA14901 for ; Sun, 4 Jan 2004 20:23:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdJSd-0003Iz-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 20:23:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdJQV-0003Ed-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 20:21:04 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AdJPa-000392-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 20:20:07 -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 <0HQZ00209SZYYR@mailout1.samsung.com> for dhcwg@ietf.org; Mon, 05 Jan 2004 10:19:10 +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 <0HQZ00KMQSZWEC@mailout1.samsung.com> for dhcwg@ietf.org; Mon, 05 Jan 2004 10:19:09 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HQZ00EY0SZWC8@mmp1.samsung.com> for dhcwg@ietf.org; Mon, 05 Jan 2004 10:19:08 +0900 (KST) Date: Mon, 05 Jan 2004 10:19:52 +0900 From: Soohong Daniel Park Subject: RE: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt In-reply-to: <4.3.2.7.2.20040102104312.01e3c220@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <00a501c3d32a$056de080$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Changed subject is easier than before to make sense what this draft is ...IMHO. 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: Saturday, January 03, 2004 12:58 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt > > > The IESG is reviewing draft-ietf-dhc-dhcpv6-stateless-03.txt, > "A Guide to > Implementing Stateless DHCPv6 Service". There is a request > to change the > title to simply "Stateless DHCPv6 Service", because the > document defines a > subset of RFC 3315, rather than giving a guide to > implementing RFC 3315. > > I am concerned that there has been confusion in the past that > draft-ietf-dhc-dhcpv6-stateless-03.txt is simply a reference > into RFC 3315, > and that draft-ietf-dhc-dhcpv6-stateless-03.txt does *not* > describe a new > protocol. If the WG is confident that the change won't add > to the potential > for confusion and there are no other objections, I'll change > the title of > draft-ietf-dhc-dhcpv6-stateless-03.txt to "Stateless DHCPv6 Service" > > - 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 Sun Jan 4 21:24:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16054; Sun, 4 Jan 2004 21:24: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 1AdKPR-0001mz-P9; Sun, 04 Jan 2004 21: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 1AdKOg-0001ls-CO for dhcwg@optimus.ietf.org; Sun, 04 Jan 2004 21:23: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 VAA15978 for ; Sun, 4 Jan 2004 21:23:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdKOd-0005Cn-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 21:23:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdKJ8-000544-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 21:17:31 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AdKFJ-0004tW-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 21:13:33 -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 <0HQZ00801UABAV@endeavor.poss.com> for dhcwg@ietf.org; Sun, 04 Jan 2004 21:12:38 -0500 (EST) Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HQZ005THVH0DS@endeavor.poss.com> for dhcwg@ietf.org; Sun, 04 Jan 2004 21:12:37 -0500 (EST) Date: Sun, 04 Jan 2004 21:12:51 -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] Delivery of DHCPACK and DHCPNAK Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.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 a little unclear on the delivery of ACK and NAK to the client in specific situations. If the client is in the REQUESTING state, we assume that the client is not yet fully configured and send the DHCPACK as a broadcast if the broadcast flag is set and unicast if the flag is cleared. In the REQUESTING state we send DHCPNAK as a broadcast since there is no other valid way to deliver the message. If the client is in the RENEWING state both DHCPACK and DHCPNAK can be delivered as unicast since the client is fully configured. If the client is in the REBINDING state, how are the ACK and NAK delivered? Section 4.1 of 2131 seems to indicate that an ACK or NAK would be unicast in the REBINDING state since ciaddr would be non-zero. Is this correct? No other sections seem to address this particular aspect of REBINDING even though similar questions are addressed for the other states. Similarly, how should the ACK and NAK be delivered if the client is in INIT-REBOOT or REBOOTING state? Would the ACK be delivered based on the broadcast flag and a NAK would be broadcast? I am specifically interested in delivery *to the client*. Obviously the server will change its behavior based on contents of giaddr, ciaddr, broadcast flag, etc. So my questions are specific to the segment on which the client resides. Perhaps making the assumption that client and server are on the same network segment will make it more clear. --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 Sun Jan 4 21:38:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16395; Sun, 4 Jan 2004 21:38: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 1AdKcz-0002Ub-OP; Sun, 04 Jan 2004 21:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdKc5-0002E5-SU for dhcwg@optimus.ietf.org; Sun, 04 Jan 2004 21:37: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 VAA16390 for ; Sun, 4 Jan 2004 21:37:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdKc3-0005qQ-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 21:37:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdKaD-0005my-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 21:35:09 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AdKZS-0005jq-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 21:34:22 -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 <0HQZ00A01WGGLW@endeavor.poss.com> for dhcwg@ietf.org; Sun, 04 Jan 2004 21:33:52 -0500 (EST) Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HQZ005UBWGEDS@endeavor.poss.com> for dhcwg@ietf.org; Sun, 04 Jan 2004 21:33:52 -0500 (EST) Date: Sun, 04 Jan 2004 21:34:05 -0500 From: "Kevin A. Noll" 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=iso-8859-1 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] Meaning of NAK in RENEWING and REBINDING state? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.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 Reading through my last question to the WG I had to ask another question... What exactly is the meaning of a NAK sent to a client that is attempting to renew or rebind? Based on the state machine diagram, it would seem that a NAK in response to a renew or rebind would mean that the client's lease is being revoked prior to the lease period. Is this correct? If it is, then what is the proper way for a server to respond to a renew or rebind if it wants to allow the client to use its current lease, but not extend the lease? Section 4.4.5 of 2131 seems to say that the server should return T1 and T2 in an ACK based upon how long it wishes the client to continue using the lease. It seems, though, that using this method it would be possible to get into a situation where T1 and T2 are adjusted such that the client must attempt renewal at smaller and smaller intervals up until the lease expires. e.g. if the original lease is 60sec... - the client attempts renewal at 30secs - the server doesn't wish to extend the lease, but also doesn't want to revoke the lease, so it returns T1=15secs, T2=7secs - the client attempts renewal again at 15 secs - server sets T1=7secs, T2=4secs - client renews at 7 secs - server sets T1=3secs, T2=1sec - client renews at 3 secs - server sets T1=1sec, T2=0sec - client renews at 1sec - lease expires Is this correct interpretation or did I miss a clarification in another section? --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 Sun Jan 4 22:24:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17365; Sun, 4 Jan 2004 22:24:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdLLU-00040M-J9; Sun, 04 Jan 2004 22: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 1AdLKm-0003zl-97 for dhcwg@optimus.ietf.org; Sun, 04 Jan 2004 22:23: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 WAA17334 for ; Sun, 4 Jan 2004 22:23:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdLKj-0007W0-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 22:23:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdLJP-0007Pd-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 22:21:52 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AdLFD-00076G-00 for dhcwg@ietf.org; Sun, 04 Jan 2004 22:17:31 -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 i053GaGn085825; Sun, 4 Jan 2004 22:16:46 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Kevin A. Noll'" Cc: Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Sun, 4 Jan 2004 22:16:25 -0500 Message-ID: <000001c3d33a$515d2a90$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 See section 2.17 of http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt. (Last three paragraphs of section 4.1 of RFC 2131 discuss the general case for server/relay to client communication.) Also, keep in mind that the client's state is not something that the server easily knows and it really doesn't need to. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Kevin A. Noll Sent: Sunday, January 04, 2004 9:13 PM To: dhcwg@ietf.org Subject: [dhcwg] Delivery of DHCPACK and DHCPNAK I'm a little unclear on the delivery of ACK and NAK to the client in specific situations. If the client is in the REQUESTING state, we assume that the client is not yet fully configured and send the DHCPACK as a broadcast if the broadcast flag is set and unicast if the flag is cleared. In the REQUESTING state we send DHCPNAK as a broadcast since there is no other valid way to deliver the message. If the client is in the RENEWING state both DHCPACK and DHCPNAK can be delivered as unicast since the client is fully configured. If the client is in the REBINDING state, how are the ACK and NAK delivered? Section 4.1 of 2131 seems to indicate that an ACK or NAK would be unicast in the REBINDING state since ciaddr would be non-zero. Is this correct? No other sections seem to address this particular aspect of REBINDING even though similar questions are addressed for the other states. Similarly, how should the ACK and NAK be delivered if the client is in INIT-REBOOT or REBOOTING state? Would the ACK be delivered based on the broadcast flag and a NAK would be broadcast? I am specifically interested in delivery *to the client*. Obviously the server will change its behavior based on contents of giaddr, ciaddr, broadcast flag, etc. So my questions are specific to the segment on which the client resides. Perhaps making the assumption that client and server are on the same network segment will make it more clear. --kan-- -- Kevin A. Noll, KD4WOZ CCIE 10948, CCDP Perfect Order, Inc. Kevin.Noll@perfectorder.com 717-796-1936 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 08:34:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17332; Mon, 5 Jan 2004 08: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 1AdUrp-0003Cr-0t; Mon, 05 Jan 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdUrA-0003CI-5v for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 08:33: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 IAA17289 for ; Mon, 5 Jan 2004 08:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdUr8-00039h-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 08:33:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdUpJ-00036c-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 08:31:25 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AdUo1-00031z-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 08:30:05 -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 i05DTN1k004288; Mon, 5 Jan 2004 14:29:23 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id i05DTNkj023312; Mon, 5 Jan 2004 14:29:23 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i05DTMVV023308; Mon, 5 Jan 2004 14:29:22 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 5 Jan 2004 14:24:24 +0100 From: Stig Venaas To: Ralph Droms Cc: Bernie Volz , dhcwg@ietf.org Subject: Re: [dhcwg] Title for draft-ietf-dhc-dhcpv6-stateless-03.txt Message-ID: <20040105132424.GE23013@sverresborg.uninett.no> References: <4.3.2.7.2.20040102104312.01e3c220@flask.cisco.com> <4.3.2.7.2.20040102130600.01e658f0@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.20040102130600.01e658f0@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=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: , On Fri, Jan 02, 2004 at 01:16:03PM -0500, Ralph Droms wrote: [...] > Regarding DHCPv6 vs. DHCP - I looked back and found we weren't consistent > in RFC 3315, using mostly DHCP but also using DHCPv6 on a few (apparently > random) occasions. Either DHCP or DHCPv6 would be OK with me. Anyone > else have a preference? I'll be sure the doc is consistent, whichever term > we decide to use. Personally I don't like the term DHCPv6 (in general adding v4/v6 to some acronym). It sounds more like the 6th version of something. Since you only talk about IPv6 DHCP in the document, I would much rather you say that DHCP refers to DHCP for IPv6 like in RFC 3315. To me, DHCPv6 is just a nickname. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 09:42:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18421; Mon, 5 Jan 2004 09:42: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 1AdVvd-0005SZ-1R; Mon, 05 Jan 2004 09: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 1AdVux-0005S0-Lp for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 09:41: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 JAA18392 for ; Mon, 5 Jan 2004 09:41:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdVuv-00054X-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 09:41:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdVt6-00051c-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 09:39:24 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AdVrt-0004yE-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 09:38:09 -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 <0HR000501T14H6@endeavor.poss.com> for dhcwg@ietf.org; Mon, 05 Jan 2004 09:37:39 -0500 (EST) Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HR000CIJTYPEP@endeavor.poss.com>; Mon, 05 Jan 2004 09:37:38 -0500 (EST) Date: Mon, 05 Jan 2004 09:37:49 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK In-reply-to: <000001c3d33a$515d2a90$6401a8c0@BVolz> To: Bernie Volz 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 Thanks for pointing me to that draft. I understand that the server does not keep track of (nor easily know) the client's state. It would be much clearer if message transmission (at least for the server) were described exclusively in the context of message type or in terms of the contents of the matching request. However, message transmission includes reference to the client state. Those references are what I'm trying to clarify for myself. I haven't attempted this, but I suppose if I were to map the client state to the request message contents, I may be able to describe server-side message transmission exclusvely in terms of request contents. Also, draft-ietf-dhc-implementation-01.txt doesn't appear to clarify delivery of the ACK. Can I safely assume that ACK's are delivered based on the BROADCAST flag in all client states? That wouldn't seem to be a good assumption since you should be able to deliver an ACK via unicast when you are renewing or rebinding (i.e. based on ciaddr being non-zero). --kan-- > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Bernie Volz > Sent: Sunday, 04 January, 2004 10:16 PM > To: 'Kevin A. Noll' > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK > > > See section 2.17 of > http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt. > (Last three paragraphs of section 4.1 of RFC 2131 discuss the general case > for server/relay to client communication.) > > Also, keep in mind that the client's state is not something that > the server > easily knows and it really doesn't need to. > > - Bernie > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 10:17:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20234; Mon, 5 Jan 2004 10:17: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 1AdWTV-0006be-Lc; Mon, 05 Jan 2004 10: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 1AdWSd-0006aL-By for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 10:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20120 for ; Mon, 5 Jan 2004 10:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdWSW-0006Bh-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 10:16:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdWOR-00062r-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 10:11:47 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AdWJf-0005s3-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 10:06:51 -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 <0HR000701UFXPS@endeavor.poss.com> for dhcwg@ietf.org; Mon, 05 Jan 2004 10:06:10 -0500 (EST) Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HR000CT3VA9EP@endeavor.poss.com> for dhcwg@ietf.org; Mon, 05 Jan 2004 10:06:10 -0500 (EST) Date: Mon, 05 Jan 2004 10:06:21 -0500 From: "Kevin A. Noll" In-reply-to: <000001c3d33a$515d2a90$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] Comments re: draft-ietf-dhc-implementation-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: , Content-Transfer-Encoding: 7BIT After Bernie's suggestion to read draft-ietf-dhc-implementation-01.txt, I have some comments and questions about the draft. Section 2.13 How do you support the claim that clients do not send messages in the RENEWING or REBINDING states? At a minimum a DHCPREQUEST would be broadcast from the RENEWING state as the client moves to the REBINDING state, wouldn't it? Section 2.26 states "[see also general comment below about policy.]" What section does this refer to? It appears to refer to sectoin 2.3, but that is above, not below. --kan-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 14:48:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29759; Mon, 5 Jan 2004 14:48: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 1Adahk-0001Ic-Uw; Mon, 05 Jan 2004 14: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 1AdahB-0001GG-Q3 for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 14:47:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29734 for ; Mon, 5 Jan 2004 14:47:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adah9-0002EQ-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 14:47:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdafK-0002Av-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 14:45:32 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1AdaeB-000277-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 14:44:19 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AdadW-0004kH-00; Mon, 05 Jan 2004 11:43:38 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Jan 2004 11:43:30 -0800 Message-ID: From: "Kostur, Andre" To: "'Kevin A. Noll'" , Bernie Volz Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Mon, 5 Jan 2004 11:43:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D3C4.2FD7FA00" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_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_01C3D3C4.2FD7FA00 Content-Type: text/plain; charset="iso-8859-1" RFC 2131, section 4.1: If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' field is zero and the 'ciaddr' field is nonzero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and 'yiaddr' address. In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff. Thus, if there is a valid CIADDR in the client's request, the server's reponse will be unicast back to that CIADDR. > -----Original Message----- > From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] > Sent: Monday, January 05, 2004 6:38 AM > To: Bernie Volz > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK > > > > Thanks for pointing me to that draft. > > I understand that the server does not keep track of (nor easily know) > the client's state. It would be much clearer if message transmission > (at least for the server) were described exclusively in the context of > message type or in terms of the contents of the matching request. > > However, message transmission includes reference to the client state. > Those references are what I'm trying to clarify for myself. > > I haven't attempted this, but I suppose if I were to map the client > state to the request message contents, I may be able to describe > server-side message transmission exclusvely in terms of > request contents. > > Also, draft-ietf-dhc-implementation-01.txt doesn't appear to clarify > delivery of the ACK. Can I safely assume that ACK's are > delivered based > on the BROADCAST flag in all client states? > > That wouldn't seem to be a good assumption since you should be able > to deliver an ACK via unicast when you are renewing or rebinding (i.e. > based on ciaddr being non-zero). > > --kan-- > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > > Bernie Volz > > Sent: Sunday, 04 January, 2004 10:16 PM > > To: 'Kevin A. Noll' > > Cc: dhcwg@ietf.org > > Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK > > > > > > See section 2.17 of > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt. > (Last three paragraphs of section 4.1 of RFC 2131 discuss the general case > for server/relay to client communication.) > > Also, keep in mind that the client's state is not something that > the server > easily knows and it really doesn't need to. > > - Bernie > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C3D3C4.2FD7FA00 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Delivery of DHCPACK and DHCPNAK

RFC 2131, section 4.1:

   If the 'giaddr' field in a DHCP message from a client is non-zero,
   the server sends any return messages to the 'DHCP server' port on the
   BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
   field is zero and the 'ciaddr' field is nonzero, then the server
   unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
   If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
   set, then the server broadcasts DHCPOFFER and DHCPACK messages to
   0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
   'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
   messages to the client's hardware address and 'yiaddr' address.  In
   all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
   messages to 0xffffffff.

Thus, if there is a valid CIADDR in the client's request, the server's reponse will be unicast back to that CIADDR.

> -----Original Message-----
> From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com]
> Sent: Monday, January 05, 2004 6:38 AM
> To: Bernie Volz
> Cc: dhcwg@ietf.org
> Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK
>
>
>
> Thanks for pointing me to that draft.
>
> I understand that the server does not keep track of (nor easily know)
> the client's state. It would be much clearer if message transmission
> (at least for the server) were described exclusively in the context of
> message type or in terms of the contents of the matching request.
>
> However, message transmission includes reference to the client state.
> Those references are what I'm trying to clarify for myself.
>
> I haven't attempted this, but I suppose if I were to map the client
> state to the request message contents, I may be able to describe
> server-side message transmission exclusvely in terms of
> request contents.
>
> Also, draft-ietf-dhc-implementation-01.txt doesn't appear to clarify
> delivery of the ACK. Can I safely assume that ACK's are
> delivered based
> on the BROADCAST flag in all client states?
>
> That wouldn't seem to be a good assumption since you should be able
> to deliver an ACK via unicast when you are renewing or rebinding (i.e.
> based on ciaddr being non-zero).
>
> --kan--
>
> > -----Original Message-----
> > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
> > Bernie Volz
> > Sent: Sunday, 04 January, 2004 10:16 PM
> > To: 'Kevin A. Noll'
> > Cc: dhcwg@ietf.org
> > Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK
> >
> >
> > See section 2.17 of
> >
http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt.
> (Last three paragraphs of section 4.1 of RFC 2131 discuss the general case
> for server/relay to client communication.)
>
> Also, keep in mind that the client's state is not something that
> the server
> easily knows and it really doesn't need to.
>
> - Bernie
>


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

------_=_NextPart_001_01C3D3C4.2FD7FA00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 17:37:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08323; Mon, 5 Jan 2004 17:37: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 1AddLL-0008U2-Ep; Mon, 05 Jan 2004 17:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AddKl-0008MY-6A for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 17:36: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 RAA08169 for ; Mon, 5 Jan 2004 17:36:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AddKi-0003NM-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 17:36:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AddIc-0002xu-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 17:34:14 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AddF1-0002QW-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 17:30:31 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 81DD41B2092; Mon, 5 Jan 2004 16:25:06 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Bernie Volz , dhcwg@ietf.org, "'Kevin A. Noll'" From: Ted Lemon Subject: Re: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Mon, 5 Jan 2004 14:30:04 -0800 To: "Kostur, Andre" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 5, 2004, at 11:43 AM, Kostur, Andre wrote: > Thus, if there is a valid CIADDR in the client's request, the server's > reponse will be unicast back to that CIADDR. Actually, this is not true for DHCPNAK, which indicates that the client is not correctly configured. For DHCPNAK, the response has to be broadcast. Which means that a DHCPNAK will never get to a client unless it is in INIT-REBOOT, SELECTING or REBINDING - that is, not when it is in RENEWING. The one exception is that if the client is RENEWING, and is on the same network as the server, the DHCPNAK can get to the client. But unless the server is looking at link-layer headers, it can't know that the client is on the local network anyway, so this doesn't matter very much in practice. (See the bottom of page 23 of RFC2131). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 18:30:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11678; Mon, 5 Jan 2004 18:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeAc-0002W7-SD; Mon, 05 Jan 2004 18: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 1AdeAL-0002Uc-0v for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 18:29: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 SAA11415 for ; Mon, 5 Jan 2004 18:29:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdeAF-0007hC-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:29:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Addtb-0006Hm-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:12:30 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1AddnC-0005UY-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:05:50 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AddmB-0007Uz-00; Mon, 05 Jan 2004 15:04:47 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Jan 2004 15:04:41 -0800 Message-ID: From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: Bernie Volz , dhcwg@ietf.org, "'Kevin A. Noll'" Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Mon, 5 Jan 2004 15:04:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D3E0.48428580" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_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_01C3D3E0.48428580 Content-Type: text/plain; charset="iso-8859-1" A Client in the INIT-REBOOT state will not be filling in the CIADDR (RFC 2131, section 4.3.2). Same as in the SELECTING state (the device has no legitimate IP to put in the CIADDR). For RENEWING, the request got to the DHCP server (by unicast), so presumably (hopefully?) there's a proper route back to the client. So in those states, a unicast NAK will reach the client. REBINDING may be a different case in that the client is broadcasting the request to begin with, thus may not be coming from the correct network, so a broadcast NAK reponse to a REBIND makes sense (basically the same reasons as the INIT-REBOOT case). In this case I can see a clarification for 2131 to describe a proper NAK response in this case. > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Monday, January 05, 2004 2:30 PM > To: Kostur, Andre > Cc: Bernie Volz; dhcwg@ietf.org; 'Kevin A. Noll' > Subject: Re: [dhcwg] Delivery of DHCPACK and DHCPNAK > > > On Jan 5, 2004, at 11:43 AM, Kostur, Andre wrote: > > Thus, if there is a valid CIADDR in the client's request, > the server's > > reponse will be unicast back to that CIADDR. > > Actually, this is not true for DHCPNAK, which indicates that > the client > is not correctly configured. For DHCPNAK, the response has to be > broadcast. Which means that a DHCPNAK will never get to a client > unless it is in INIT-REBOOT, SELECTING or REBINDING - that > is, not when > it is in RENEWING. The one exception is that if the client is > RENEWING, and is on the same network as the server, the > DHCPNAK can get > to the client. But unless the server is looking at link-layer > headers, it can't know that the client is on the local > network anyway, > so this doesn't matter very much in practice. (See the > bottom of page > 23 of RFC2131). > ------_=_NextPart_001_01C3D3E0.48428580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Delivery of DHCPACK and DHCPNAK

A Client in the INIT-REBOOT state will not be filling = in the CIADDR (RFC 2131, section 4.3.2).  Same as in the SELECTING = state (the device has no legitimate IP to put in the CIADDR).  For = RENEWING, the request got to the DHCP server (by unicast), so = presumably (hopefully?) there's a proper route back to the = client.  So in those states, a unicast NAK will reach the = client.

REBINDING may be a different case in that the client = is broadcasting the request to begin with, thus may not be coming from = the correct network, so a broadcast NAK reponse to a REBIND makes sense = (basically the same reasons as the INIT-REBOOT case).  In this = case I can see a clarification for 2131 to describe a proper NAK = response in this case.

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@nominum.com]=
> Sent: Monday, January 05, 2004 2:30 PM
> To: Kostur, Andre
> Cc: Bernie Volz; dhcwg@ietf.org; 'Kevin A. = Noll'
> Subject: Re: [dhcwg] Delivery of DHCPACK and = DHCPNAK
>
>
> On Jan 5, 2004, at 11:43 AM, Kostur, Andre = wrote:
> > Thus, if there is a valid CIADDR in the = client's request,
> the server's
> > reponse will be unicast back to that = CIADDR.
>
> Actually, this is not true for DHCPNAK, which = indicates that
> the client
> is not correctly configured.   For = DHCPNAK, the response has to be
> broadcast.   Which means that a = DHCPNAK will never get to a client
> unless it is in INIT-REBOOT, SELECTING or = REBINDING - that
> is, not when
> it is in RENEWING.   The one = exception is that if the client is
> RENEWING, and is on the same network as the = server, the
> DHCPNAK can get
> to the client.   But unless the = server is looking at link-layer
> headers, it can't know that the client is on = the local
> network anyway,
> so this doesn't matter very much in = practice.   (See the
> bottom of page
> 23 of RFC2131).
>

------_=_NextPart_001_01C3D3E0.48428580-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 18:37:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12154; Mon, 5 Jan 2004 18:37:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeGP-0003FC-CF; Mon, 05 Jan 2004 18: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 1AdeFw-0003CW-Q8 for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 18:35: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 SAA11890 for ; Mon, 5 Jan 2004 18:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdeFt-0001IB-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdeB6-0000Hz-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:30:35 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AddxV-0006hP-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:16:29 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 23EAB1B2016; Mon, 5 Jan 2004 17:11:10 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <249CA3CE-3FD5-11D8-BD9C-000A95D9C74C@fugue.com> Content-Transfer-Encoding: quoted-printable Cc: Bernie Volz , dhcwg@ietf.org, "'Kevin A. Noll'" , "'Ted Lemon'" From: Ted Lemon Subject: Re: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Mon, 5 Jan 2004 15:16:08 -0800 To: "Kostur, Andre" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 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 Jan 5, 2004, at 3:04 PM, Kostur, Andre wrote: > A Client in the INIT-REBOOT state will not be filling in the CIADDR=20 > (RFC 2131, section 4.3.2).=A0 Same as in the SELECTING state (the = device=20 > has no legitimate IP to put in the CIADDR).=A0 For RENEWING, the = request=20 > got to the DHCP server (by unicast), so presumably (hopefully?)=20 > there's a proper route back to the client.=A0 So in those states, a=20 > unicast NAK will reach the client. No, because the DHCP server is sending the DHCPNAK to indicate that the=20= client's configuration is incorrect. So that means that routing back=20= to the client won't work. OTOH, routing from the client didn't work=20 either, so probably the server never got that DHCPREQUEST. > REBINDING may be a different case in that the client is broadcasting=20= > the request to begin with, thus may not be coming from the correct=20 > network, so a broadcast NAK reponse to a REBIND makes sense (basically=20= > the same reasons as the INIT-REBOOT case).=A0 In this case I can see a=20= > clarification for 2131 to describe a proper NAK response in this case. RFC2131 is quite explicit in saying that you have to broadcast DHCPNAK=20= when giaddr is zero, and you have to send the response to giaddr if it=20= is nonzero. What rfc2131 is lamentably unspecific about is when it's=20= appropriate to send a DHCPNAK. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 18:40:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13158; Mon, 5 Jan 2004 18:40: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 1AdeKJ-0003lE-I1; Mon, 05 Jan 2004 18: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 1AdeJO-0003fy-7m for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 18:39: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 SAA12552 for ; Mon, 5 Jan 2004 18:39:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdeJL-00029P-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:39:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdeEG-0000zc-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:33:50 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1Ade8i-0007RA-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 18:28:05 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1Ade7y-0007nB-00; Mon, 05 Jan 2004 15:27:18 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Jan 2004 15:27:11 -0800 Message-ID: From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: Bernie Volz , dhcwg@ietf.org, "'Kevin A. Noll'" , "'Ted Lemon'" Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Mon, 5 Jan 2004 15:27:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D3E3.6B651750" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_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_01C3D3E3.6B651750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com] > Sent: Monday, January 05, 2004 3:16 PM > To: Kostur, Andre > Cc: Bernie Volz; dhcwg@ietf.org; 'Kevin A. Noll'; 'Ted Lemon' > Subject: Re: [dhcwg] Delivery of DHCPACK and DHCPNAK >=20 > > REBINDING may be a different case in that the client is=20 > broadcasting=20 > > the request to begin with, thus may not be coming from the correct=20 > > network, so a broadcast NAK reponse to a REBIND makes sense=20 > (basically=20 > > the same reasons as the INIT-REBOOT case).=A0 In this case I=20 > can see a=20 > > clarification for 2131 to describe a proper NAK response in=20 > this case. >=20 > RFC2131 is quite explicit in saying that you have to=20 > broadcast DHCPNAK=20 > when giaddr is zero, and you have to send the response to=20 > giaddr if it=20 > is nonzero. What rfc2131 is lamentably unspecific about is=20 > when it's=20 > appropriate to send a DHCPNAK. Whups.... you're right. Heck, it's even in the paragraph that _I_ = quoted from 2131: "In all cases, when 'giaddr' is zero, the server broadcasts = any DHCPNAK messages to 0xffffffff.". Although, interestingly, the top of page 25 says "Normally, DHCP = servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery." (OK, that = probably should be "unicast"...) ------_=_NextPart_001_01C3D3E3.6B651750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Delivery of DHCPACK and DHCPNAK

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@fugue.com]
> Sent: Monday, January 05, 2004 3:16 PM
> To: Kostur, Andre
> Cc: Bernie Volz; dhcwg@ietf.org; 'Kevin A. = Noll'; 'Ted Lemon'
> Subject: Re: [dhcwg] Delivery of DHCPACK and = DHCPNAK
>
> > REBINDING may be a different case in that = the client is
> broadcasting
> > the request to begin with, thus may not be = coming from the correct
> > network, so a broadcast NAK reponse to a = REBIND makes sense
> (basically
> > the same reasons as the INIT-REBOOT = case).=A0 In this case I
> can see a
> > clarification for 2131 to describe a = proper NAK response in
> this case.
>
> RFC2131 is quite explicit in saying that you = have to
> broadcast DHCPNAK
> when giaddr is zero, and you have to send the = response to
> giaddr if it
> is nonzero.   What rfc2131 is = lamentably unspecific about is
> when it's
> appropriate to send a DHCPNAK.

Whups.... you're right.  Heck, it's even in the = paragraph that _I_ quoted from 2131: "In all cases, when 'giaddr' = is zero, the server broadcasts any DHCPNAK messages to = 0xffffffff.".

Although, interestingly, the top of page 25 says = "Normally, DHCP servers and BOOTP relay agents attempt to = deliver   DHCPOFFER, DHCPACK and DHCPNAK messages directly to = the client using uicast delivery." (OK, that probably should be = "unicast"...)

------_=_NextPart_001_01C3D3E3.6B651750-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 19:46:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16189; Mon, 5 Jan 2004 19: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 1AdfMB-00071v-GG; Mon, 05 Jan 2004 19:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfLs-00070R-7X for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 19:45: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 TAA16164 for ; Mon, 5 Jan 2004 19:45:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfLq-0006SH-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 19:45:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfK7-0006MY-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 19:43:56 -0500 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1AdfJ8-0006Ec-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 19:42:54 -0500 Received: from STEVEPC (ob.relicore.com [192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i060Ldpu015451 for ; Mon, 5 Jan 2004 19:21:40 -0500 (EST) From: "Steve Gonczi" To: Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Mon, 5 Jan 2004 19:41:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <249CA3CE-3FD5-11D8-BD9C-000A95D9C74C@fugue.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ftp.relicore.com id i060Ldpu015451 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 Looks like Andre clearly said _if_ the request got to the server. Given that the RENEW got to the server, it may make sense to unicast a DHCPNAK. I can imagine a scenario where the DHCPNAK is used merely to enforce some policy (to revoke and otherwise workable address) On Jan 5, 2004, at 3:04 PM, Kostur, Andre wrote: >> A Client in the INIT-REBOOT state will not be filling in the CIADDR >> (RFC 2131, section 4.3.2).=A0 Same as in the SELECTING state (the devi= ce >> has no legitimate IP to put in the CIADDR).=A0 For RENEWING, the reque= st >> got to the DHCP server (by unicast), so presumably (hopefully?) >> there's a proper route back to the client.=A0 So in those states, a >> unicast NAK will reach the client. OTOH, Ted Lemon said.... >No, because the DHCP server is sending the DHCPNAK to indicate that the >client's configuration is incorrect. So that means that routing back >to the client won't work. OTOH, routing from the client didn't work >either, so probably the server never got that DHCPREQUEST. Given that, probably no need to consider how a server should handle a packet it did not receive. :-) Cheers /sG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 19:56:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16483; Mon, 5 Jan 2004 19:56: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 1AdfVq-0007R6-1K; Mon, 05 Jan 2004 19: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 1AdfVI-0007Pw-Ey for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 19:55: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 TAA16473 for ; Mon, 5 Jan 2004 19:55:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfVG-0006oW-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 19:55:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfTR-0006ll-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 19:53:34 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AdfSJ-0006i0-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 19:52:23 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 110CD1B2016; Mon, 5 Jan 2004 18:47:24 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <96C28072-3FE2-11D8-BD9C-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Mon, 5 Jan 2004 16:52:23 -0800 To: "Steve Gonczi" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 5, 2004, at 4:41 PM, Steve Gonczi wrote: > Given that the RENEW got to the server, > it may make sense to unicast a DHCPNAK. > > I can imagine a scenario where the DHCPNAK is used merely > to enforce some policy (to revoke and otherwise workable > address) This is not really something that's suggested by RFC2131. DHCPNAK means the client is misconfigured for its network. Unicasting a DHCPNAK back to the client sounds like a nice DoS attack to me, not that there aren't plenty of others in DHCP. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 5 21:54:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19298; Mon, 5 Jan 2004 21:54: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 1AdhM1-0003Ct-Cp; Mon, 05 Jan 2004 21: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 1AdhLR-0003CU-TH for dhcwg@optimus.ietf.org; Mon, 05 Jan 2004 21:53:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19291 for ; Mon, 5 Jan 2004 21:53:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdhLO-0003BO-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 21:53:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdhJS-00038J-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 21:51:23 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AdhHY-000350-00 for dhcwg@ietf.org; Mon, 05 Jan 2004 21:49:24 -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 i062nGGn051572; Mon, 5 Jan 2004 21:49:25 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Steve Gonczi'" , Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK Date: Mon, 5 Jan 2004 21:49:20 -0500 Message-ID: <000101c3d3ff$b24a4980$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: 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=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 In the most likely cases of interest, the DHCPREQUEST that the server is NACKing will get to the server (see Table 4, below, copied from section 4.3.6 Client Messages of RFC 2131): --------------------------------------------------------------------- | |INIT-REBOOT |SELECTING |RENEWING |REBINDING | --------------------------------------------------------------------- |broad/unicast |broadcast |broadcast |unicast |broadcast | |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT | |requested-ip |MUST |MUST |MUST NOT |MUST NOT | |ciaddr |zero |zero |IP address |IP address| --------------------------------------------------------------------- The INIT-REBOOT and REBINDING are broadcast by the client so the server = will receive them (either directly or from a relay). The RENEWING case is unlikely to generate a DHCPNAK as a client probably hasn't move to a new network - yes, there could be a renumbering event and in this case the server might receive the message and could perhaps even send the DHCPNAK = as a unicast, but that's an edge case. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Steve Gonczi Sent: Monday, January 05, 2004 7:42 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK Looks like Andre clearly said _if_ the request got to the server. Given that the RENEW got to the server, it may make sense to unicast a DHCPNAK. I can imagine a scenario where the DHCPNAK is used merely to enforce some policy (to revoke and otherwise workable address) On Jan 5, 2004, at 3:04 PM, Kostur, Andre wrote: >> A Client in the INIT-REBOOT state will not be filling in the CIADDR >> (RFC 2131, section 4.3.2).=A0 Same as in the SELECTING state (the = device >> has no legitimate IP to put in the CIADDR).=A0 For RENEWING, the = request >> got to the DHCP server (by unicast), so presumably (hopefully?) >> there's a proper route back to the client.=A0 So in those states, a >> unicast NAK will reach the client. OTOH, Ted Lemon said.... >No, because the DHCP server is sending the DHCPNAK to indicate that the >client's configuration is incorrect. So that means that routing back >to the client won't work. OTOH, routing from the client didn't work >either, so probably the server never got that DHCPREQUEST. Given that, probably no need to consider how a server should handle a packet it did not receive. :-) Cheers /sG _______________________________________________ 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 Jan 7 16:00:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01328; Wed, 7 Jan 2004 16: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 1AeKmY-0000aE-V8; Wed, 07 Jan 2004 16: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 1AeKlx-0000ZM-RX for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 15:59: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 PAA01008; Wed, 7 Jan 2004 15:59:23 -0500 (EST) Message-Id: <200401072059.PAA01008@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, 07 Jan 2004 15:59:23 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-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 : Node-Specific Client Identifiers for DHCPv4 Author(s) : T. Lemon Filename : draft-ietf-dhc-3315id-for-v4-01.txt Pages : 8 Date : 2004-1-7 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-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-3315id-for-v4-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-3315id-for-v4-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-1-7151234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-3315id-for-v4-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-3315id-for-v4-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-7151234.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 Jan 7 16:43:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04367; Wed, 7 Jan 2004 16:43: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 1AeLS9-0003ZQ-1j; Wed, 07 Jan 2004 16: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 1AeLS6-0003Z7-Ma for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 16:42: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 QAA04172 for ; Wed, 7 Jan 2004 16:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLS1-0006ra-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 16:42:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeLNv-00061L-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 16:38:41 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AeLBi-00052Y-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 16:26:03 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 25EE51B20A5 for ; Wed, 7 Jan 2004 15:20:07 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <01B090B2-4158-11D8-96D1-000A95D9C74C@fugue.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: dhcwg@ietf.org From: Ted Lemon Date: Wed, 7 Jan 2004 13:25:24 -0800 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Request for review of 3315id 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 URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-01.txt A new rev of the 3315id-for-v4 has just come out. I'd appreciate it if people could take a look at it. In particular, I know Kim Kinnear, Ralph Droms, possibly Mark Stapp, and probably other folks had questions, and I'd like to know if those are resolved in the new draft. It's mercifully short (at least IMHO). :') Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 17:36:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10199; Wed, 7 Jan 2004 17:36: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 1AeMHR-0005wi-Jg; Wed, 07 Jan 2004 17: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 1AeMGn-0005sA-E0 for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 17:35: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 RAA09950 for ; Wed, 7 Jan 2004 17:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMGk-00053R-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:35:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMBB-0004mi-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:29:34 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1AeM6z-0004Wm-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:25:13 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i07MNkrE197780; Wed, 7 Jan 2004 17:23:46 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i07MNjS0069450; Wed, 7 Jan 2004 15:23:46 -0700 Received: from login-2.austin.ibm.com (login-2.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id i07MNj1Z040804; Wed, 7 Jan 2004 16:23:45 -0600 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by login-2.austin.ibm.com (AIX4.3/8.9.3p2/8.7-client1.01) with ESMTP id QAA39618; Wed, 7 Jan 2004 16:20:49 -0600 Message-ID: <3FFC86EB.2EFA94E4@austin.ibm.com> Date: Wed, 07 Jan 2004 16:23:39 -0600 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: Ted Lemon CC: dhcwg@ietf.org Subject: Re: [dhcwg] Request for review of 3315id draft... References: <01B090B2-4158-11D8-96D1-000A95D9C74C@fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.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 Hi Ted, Section 4.1 DHCP clients that support more than one network interface SHOULD use the same client identifier on each interface. Such DHCP clients SHOULD be prepared for the possibility that the DHCP server will allocate the same IP address to both interfaces. We can solve this problem by making an addition Code Len Type Index DHCP Unique Identifier +-----+-----+-----+-----+-----+-----+-----+--- | 61 | n | 255 | Index | d1 | d2 | d3 | d4 | ... +-----+-----+-----+-----+-----+-----+-----+--- Where Index is the interface index. Thanks Vasu Vallabhaneni Ted Lemon wrote: > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-01.txt > > A new rev of the 3315id-for-v4 has just come out. I'd appreciate it > if people could take a look at it. In particular, I know Kim Kinnear, > Ralph Droms, possibly Mark Stapp, and probably other folks had > questions, and I'd like to know if those are resolved in the new draft. > It's mercifully short (at least IMHO). :') > > Thanks! > > _______________________________________________ > 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 Jan 7 17:45:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10705; Wed, 7 Jan 2004 17: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 1AeMQ9-0006fT-Kz; Wed, 07 Jan 2004 17: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 1AeMPL-0006eM-HN for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 17:44: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 RAA10657 for ; Wed, 7 Jan 2004 17:44:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMPJ-0005ot-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:44:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMNU-0005kQ-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:42:16 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AeMM1-0005fd-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:40:46 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 87DA31B2003; Wed, 7 Jan 2004 16:35:26 -0600 (CST) In-Reply-To: <3FFC86EB.2EFA94E4@austin.ibm.com> References: <01B090B2-4158-11D8-96D1-000A95D9C74C@fugue.com> <3FFC86EB.2EFA94E4@austin.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8823792E-4162-11D8-96D1-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 14:40:45 -0800 To: "Vasu, Vallabhaneni" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Adding an interface identifier doesn't really solve the problem unless we also require the server to treat the interface identifier as not being part of the client identifier. I think that's too big a change. Furthermore, a server that follows the current protocol specification won't have a problem. So I think just putting in verbiage that says "follow the spec" is enough, and adding additional complexity isn't going to help. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 17:51:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10877; Wed, 7 Jan 2004 17:51: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 1AeMVy-0006wl-Eb; Wed, 07 Jan 2004 17:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMVE-0006u8-QL for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 17:50: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 RAA10847 for ; Wed, 7 Jan 2004 17:50:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMVC-00067M-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:50:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMTE-000604-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:48:13 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1AeMRL-0005sH-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:46:15 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AeMQa-0003X0-00; Wed, 07 Jan 2004 14:45:28 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jan 2004 14:45:20 -0800 Message-ID: From: "Kostur, Andre" To: "'Vasu, Vallabhaneni'" , Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 14:45:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D56F.ED9C8590" 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_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_01C3D56F.ED9C8590 Content-Type: text/plain; charset="iso-8859-1" > From: Vasu, Vallabhaneni [mailto:vasu@austin.ibm.com] > Sent: Wednesday, January 07, 2004 2:24 PM > To: Ted Lemon > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Request for review of 3315id draft... > > Hi Ted, > > Section 4.1 > > DHCP clients that support more than one network interface SHOULD > use the same client identifier on each interface. Such DHCP > clients SHOULD be prepared for the possibility that the DHCP server > will allocate the same IP address to both interfaces. > > We can solve this problem by making an addition Huh? What problem? The point was to _not_ distinguish between the different interfaces. If the different interfaces are intended to have different IPs, then one could use different DUIDs to represent that. > Code Len Type Index > DHCP Unique > Identifier > +-----+-----+-----+-----+-----+-----+-----+--- > | 61 | n | 255 | Index | > d1 | d2 | d3 | d4 | ... > +-----+-----+-----+-----+-----+-----+-----+--- > > Where Index is the interface index. > > Thanks > Vasu Vallabhaneni > > Ted Lemon wrote: > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-01.txt > > A new rev of the 3315id-for-v4 has just come out. I'd appreciate it > if people could take a look at it. In particular, I know Kim Kinnear, > Ralph Droms, possibly Mark Stapp, and probably other folks had > questions, and I'd like to know if those are resolved in the new draft. > It's mercifully short (at least IMHO). :') ------_=_NextPart_001_01C3D56F.ED9C8590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Request for review of 3315id draft...

> From: Vasu, Vallabhaneni [mailto:vasu@austin.ibm.com]
> Sent: Wednesday, January 07, 2004 2:24 = PM
> To: Ted Lemon
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] Request for review of = 3315id draft...
>
> Hi Ted,
>
> Section 4.1
>
> DHCP clients that support more than one network = interface SHOULD
>  use the same client identifier on each = interface.  Such DHCP
>  clients SHOULD be prepared for the = possibility that the DHCP server
>    will allocate the same IP = address to both interfaces.
>
> We can solve this problem by making an = addition

Huh?  What problem?  The point was to _not_ = distinguish between the different interfaces.  If the different = interfaces are intended to have different IPs, then one could use = different DUIDs to represent that.

>          = ; Code        = Len         = Type      = Index            =
> DHCP Unique
> Identifier
>       = +-----+-----+-----+-----+-----+-----+-----+---
>       = |     61        = |      = n        |    = 255      |  Index   |
> d1       = |   d2         = |     d3       = |    d4 | ...
>       = +-----+-----+-----+-----+-----+-----+-----+---
>
> Where Index is the interface index.
>
> Thanks
> Vasu Vallabhaneni
>
> Ted Lemon wrote:
>
> > > A URL for this Internet-Draft = is:
> > >
http://www.ietf.org/internet-drafts/draft-ietf-dhc-331= 5id-for-v4-01.txt
>
> A new rev of the 3315id-for-v4 has just come = out.   I'd appreciate it
> if people could take a look at it.   = In particular, I know Kim Kinnear,
> Ralph Droms, possibly Mark Stapp, and probably = other folks had
> questions, and I'd like to know if those are = resolved in the new draft.
>    It's mercifully short (at = least IMHO).   :')

------_=_NextPart_001_01C3D56F.ED9C8590-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 18:03:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11389; Wed, 7 Jan 2004 18:03: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 1AeMhZ-0007Pp-BP; Wed, 07 Jan 2004 18:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMgy-0007Oz-TE for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 18:02: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 SAA11335 for ; Wed, 7 Jan 2004 18:02:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMgw-0006kX-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:02:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMf5-0006fq-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:00:28 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AeMeX-0006b9-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 17:59:53 -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 i07Mxh57039963; Wed, 7 Jan 2004 17:59:52 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" , Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 17:59:50 -0500 Message-ID: <000001c3d571$f79f2a50$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: <01B090B2-4158-11D8-96D1-000A95D9C74C@fugue.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 Ted: The draft looks great. A few nits: - In section 2.2, you say "Case (a) is problematic, and is beyond the = scope of this document." I'm not sure why it is problematic, especially in the context of what you're trying to discuss here. The only problem I could = see is if a client used the same client identifier when configuring both interfaces and a single DHCP server services the client on both networks = and does not allow a client to have multiple addresses (even when on = different networks). - Also in section 2.2 (really section 3 where it discusses the solution = for 2.2), this MAY require a change to existing protocol stacks. For = example, I use Windows XP and have the (b) case of 2.2 and it does get two = different IP address on the same network (not a problem in my home network). It = handles this just fine. Not sure how it might handle it if the same address was returned. Not sure what to do about it, just that it may be a problem = for some implementations that never expect two IPv4 interfaces to have the = same address. I wonder whether IPv6 stacks might also have issues here as if = they do DAD, might not the other interface receive the message and the stack = thus believes the address is duplicated? IPv4 implementations could have some = ARP issues! Perhaps we should tread a bit more carefully here??? - On the last line of Page 4 (Section 4.1), you have an extra "To send = a". - I also wonder whether the IANA considerations should really request dropping tracking of the type field. I think it is important we keep the current assignments as I suspect they will be used for long periods of = time. Perhaps this is a non-issue anyway since IANA doesn't really track these (just the ARP hardware type codes). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted Lemon Sent: Wednesday, January 07, 2004 4:25 PM To: dhcwg@ietf.org Subject: [dhcwg] Request for review of 3315id draft... > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-01.txt A new rev of the 3315id-for-v4 has just come out. I'd appreciate it=20 if people could take a look at it. In particular, I know Kim Kinnear,=20 Ralph Droms, possibly Mark Stapp, and probably other folks had=20 questions, and I'd like to know if those are resolved in the new draft.=20 It's mercifully short (at least IMHO). :') Thanks! _______________________________________________ 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 Jan 7 18:29:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13227; Wed, 7 Jan 2004 18:29: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 1AeN6k-0000Rh-GJ; Wed, 07 Jan 2004 18: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 1AeN6D-0000R6-AI for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 18:28: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 SAA13212 for ; Wed, 7 Jan 2004 18:28:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeN65-0007dG-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:28:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeN1z-0007X3-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:24:08 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AeMxL-0007NA-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:19:20 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id AD9031B200C; Wed, 7 Jan 2004 17:13:45 -0600 (CST) In-Reply-To: <000001c3d571$f79f2a50$6401a8c0@BVolz> References: <000001c3d571$f79f2a50$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 15:19:04 -0800 To: "Bernie Volz" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > - In section 2.2, you say "Case (a) is problematic, and is beyond the > scope > of this document." I'm not sure why it is problematic, especially in > the > context of what you're trying to discuss here. The only problem I > could see > is if a client used the same client identifier when configuring both > interfaces and a single DHCP server services the client on both > networks and > does not allow a client to have multiple addresses (even when on > different > networks). If a client is multiply-connected and asks the DHCP server on both interfaces to update its domain name as "foo", what does the DHCP server do? Are there two A records on "foo"? Only one? Which one? Do they alternate if the renewals are out of sync? What if one interface is served by a different DHCP server than the other? Maybe I need to add some text to explain why this is problematic? > - Also in section 2.2 (really section 3 where it discusses the > solution for > 2.2), this MAY require a change to existing protocol stacks. For > example, I > use Windows XP and have the (b) case of 2.2 and it does get two > different IP > address on the same network (not a problem in my home network). It > handles > this just fine. Not sure how it might handle it if the same address was > returned. Not sure what to do about it, just that it may be a problem > for > some implementations that never expect two IPv4 interfaces to have the > same > address. I wonder whether IPv6 stacks might also have issues here as > if they > do DAD, might not the other interface receive the message and the > stack thus > believes the address is duplicated? IPv4 implementations could have > some ARP > issues! Perhaps we should tread a bit more carefully here??? Yes, this is dicey. The alternative is to do as Vasu suggested (apologies for misunderstanding the context of his suggestion, BTW) and send an interface ID on each interface, and let the client always get two IP addresses, whether both interfaces are on the same network or not. I don't think that's the right answer. > - On the last line of Page 4 (Section 4.1), you have an extra "To send > a". Fixed, thanks. > - I also wonder whether the IANA considerations should really request > dropping tracking of the type field. I think it is important we keep > the > current assignments as I suspect they will be used for long periods of > time. > Perhaps this is a non-issue anyway since IANA doesn't really track > these > (just the ARP hardware type codes). I wasn't proposing that we drop existing tracking, but rather that we say we will never define any new types, and therefore the IANA doesn't need to have a continuing tracking process. Do you think the wording needs to be tweaked, then? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 18:37:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13689; Wed, 7 Jan 2004 18:37: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 1AeNES-00014T-UR; Wed, 07 Jan 2004 18:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeNDj-00013H-JC for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 18:36: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 SAA13602 for ; Wed, 7 Jan 2004 18:36:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeNDg-0000Js-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:36:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeNBp-0000D0-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:34:18 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AeNAl-00002u-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:33:11 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i07NWdlS407960; Wed, 7 Jan 2004 18:32:39 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i07NWcSo162386; Wed, 7 Jan 2004 16:32:38 -0700 Received: from login-2.austin.ibm.com (login-2.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id i07NWc1Z053086; Wed, 7 Jan 2004 17:32:38 -0600 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by login-2.austin.ibm.com (AIX4.3/8.9.3p2/8.7-client1.01) with ESMTP id RAA46782; Wed, 7 Jan 2004 17:29:44 -0600 Message-ID: <3FFC9714.7765BD96@austin.ibm.com> Date: Wed, 07 Jan 2004 17:32:37 -0600 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: "Kostur, Andre" CC: Ted Lemon , dhcwg@ietf.org Subject: Re: [dhcwg] Request for review of 3315id draft... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=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 Correct me if I am wrong. I thought as per RFC 3315 a system is supposed to have only one DUID. The reason I suggested using interface index asI know of many customers who have systems with two interface on the same subnet. Now with this change one of the interface will not get IP address. Thanks Vasu Vallabhaneni "Kostur, Andre" wrote: > Part 1.1Type: Plain Text (text/plain) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 18:47:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14026; Wed, 7 Jan 2004 18:47: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 1AeNO8-0001bb-PK; Wed, 07 Jan 2004 18:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeNNT-0001ap-Bi for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 18:46: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 SAA14016 for ; Wed, 7 Jan 2004 18:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeNNQ-0000kV-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:46:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeNLh-0000gw-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:44:29 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AeNKi-0000cp-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:43: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 i07NhIGn040014; Wed, 7 Jan 2004 18:43:27 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" Cc: Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 18:43:25 -0500 Message-ID: <000001c3d578$0e57c210$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 My comments below, prefixed by BV>. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@fugue.com]=20 Sent: Wednesday, January 07, 2004 6:19 PM To: Bernie Volz Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Request for review of 3315id draft... > - In section 2.2, you say "Case (a) is problematic, and is beyond the=20 > scope > of this document." I'm not sure why it is problematic, especially in=20 > the > context of what you're trying to discuss here. The only problem I=20 > could see > is if a client used the same client identifier when configuring both > interfaces and a single DHCP server services the client on both=20 > networks and > does not allow a client to have multiple addresses (even when on=20 > different > networks). If a client is multiply-connected and asks the DHCP server on both=20 interfaces to update its domain name as "foo", what does the DHCP=20 server do? Are there two A records on "foo"? Only one? Which one?=20 Do they alternate if the renewals are out of sync? What if one=20 interface is served by a different DHCP server than the other? Maybe=20 I need to add some text to explain why this is problematic? BV> OK, yes those are problems, though I think the DNS/DHCP interactions stuff should support these operations if the DUID is used as the client identifier. > - Also in section 2.2 (really section 3 where it discusses the=20 > solution for > 2.2), this MAY require a change to existing protocol stacks. For=20 > example, I > use Windows XP and have the (b) case of 2.2 and it does get two=20 > different IP > address on the same network (not a problem in my home network). It=20 > handles > this just fine. Not sure how it might handle it if the same address = was > returned. Not sure what to do about it, just that it may be a problem=20 > for > some implementations that never expect two IPv4 interfaces to have the = > same > address. I wonder whether IPv6 stacks might also have issues here as=20 > if they > do DAD, might not the other interface receive the message and the=20 > stack thus > believes the address is duplicated? IPv4 implementations could have=20 > some ARP > issues! Perhaps we should tread a bit more carefully here??? Yes, this is dicey. The alternative is to do as Vasu suggested=20 (apologies for misunderstanding the context of his suggestion, BTW) and=20 send an interface ID on each interface, and let the client always get=20 two IP addresses, whether both interfaces are on the same network or=20 not. I don't think that's the right answer. BV> Yeah, I'd like to avoid the Interface Identifier as well!!! I think = you need to point out the impact so that people that want to switch to using = the DUID take this into account. > - On the last line of Page 4 (Section 4.1), you have an extra "To send = > a". Fixed, thanks. > - I also wonder whether the IANA considerations should really request > dropping tracking of the type field. I think it is important we keep=20 > the > current assignments as I suspect they will be used for long periods of = > time. > Perhaps this is a non-issue anyway since IANA doesn't really track=20 > these > (just the ARP hardware type codes). I wasn't proposing that we drop existing tracking, but rather that we=20 say we will never define any new types, and therefore the IANA doesn't=20 need to have a continuing tracking process. Do you think the wording=20 needs to be tweaked, then? BV> But I also think we should allow for a new hardware type to come = along and be used with DHCP clients that might want to use the existing = format? So, I'd rather you just say 255 is for the DUID and leave it at that? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 18:55:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14304; Wed, 7 Jan 2004 18:55: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 1AeNVv-0001pV-4J; Wed, 07 Jan 2004 18: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 1AeNVM-0001of-Vd for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 18:54: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 SAA14292 for ; Wed, 7 Jan 2004 18:54:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeNVG-000156-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:54:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeNTa-000112-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:52:39 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AeNSz-0000wO-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:52:01 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 803441B200C; Wed, 7 Jan 2004 17:46:41 -0600 (CST) In-Reply-To: <3FFC9714.7765BD96@austin.ibm.com> References: <3FFC9714.7765BD96@austin.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C2561A2-416C-11D8-96D1-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 15:52:00 -0800 To: "Vasu, Vallabhaneni" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 7, 2004, at 3:32 PM, Vasu, Vallabhaneni wrote: > The reason I suggested using interface index asI know of many customers > who have systems with two interface on the same subnet. Now with this > change one of the interface will not get IP address. No, they'll both get the same IP address. Can you explain why it's useful to have two interfaces attached to the same wire with different IP addresses acquired through DHCP? I should point out that if you want to have two separate identities, you should generate two separate identities, and this is actually orthogonal to the question of whether you have more than one interface. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 18:59:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14449; Wed, 7 Jan 2004 18:59: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 1AeNZm-0001zO-0r; Wed, 07 Jan 2004 18:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeNZ8-0001yY-VE for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 18:58: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 SAA14421 for ; Wed, 7 Jan 2004 18:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeNZ5-0001Ff-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:58:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeNXH-0001Bf-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:56:28 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AeNWQ-00016m-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:55:34 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 21E6F1B2003; Wed, 7 Jan 2004 17:50:15 -0600 (CST) In-Reply-To: <000001c3d578$0e57c210$6401a8c0@BVolz> References: <000001c3d578$0e57c210$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 15:55:34 -0800 To: "Bernie Volz" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 7, 2004, at 3:43 PM, Bernie Volz wrote: > But I also think we should allow for a new hardware type to come along > and be used with DHCP clients that might want to use the existing > format? > So, I'd rather you just say 255 is for the DUID and leave it at that? It certainly wasn't my intention that following this document should be optional, except in the sense that clients that haven't been upgraded still need to be supported. The way client identifiers are currently being done is broken. This document is a proposal to fix it. Part of fixing it is that the old way of doing it is deprecated. Adding new identifier types would be a mistake, IMHO. If you want to add a new identifier type, add a new 3315-style DUID. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 19:03:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14642; Wed, 7 Jan 2004 19:03: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 1AeNdc-0002St-Le; Wed, 07 Jan 2004 19: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 1AeNcy-0002H3-8V for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 19:02: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 TAA14538 for ; Wed, 7 Jan 2004 19:02:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeNcv-0001RN-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 19:02:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeNb1-0001LD-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 19:00:19 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AeNZR-0001HC-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:58:41 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 57FB71B2003; Wed, 7 Jan 2004 17:53:22 -0600 (CST) In-Reply-To: <000001c3d578$0e57c210$6401a8c0@BVolz> References: <000001c3d578$0e57c210$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B484624-416D-11D8-96D1-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 15:58:41 -0800 To: "Bernie Volz" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 7, 2004, at 3:43 PM, Bernie Volz wrote: > BV> Yeah, I'd like to avoid the Interface Identifier as well!!! I > think you > need to point out the impact so that people that want to switch to > using the > DUID take this into account. I don't see the value in adding any more text here. Do you have a proposal for what you want added? The text already points out that the client has to handle this case. I don't want to specify how the client handles it, just that it has to handle it. Otherwise we're opening a really big can of worms. I think anybody serious implementor is going to have to wrestle with how to deal with this. Maybe when they have some implementation experience *they* can write it up. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 19:36:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15798; Wed, 7 Jan 2004 19:36:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeO9Z-00042F-8M; Wed, 07 Jan 2004 19: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 1AeO8d-0003kG-BH for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 19:35: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 TAA15640 for ; Wed, 7 Jan 2004 19:34:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeO8b-00033t-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 19:35:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeO6v-0002wR-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 19:33:17 -0500 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1AeO2Z-0002kg-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 19:28:47 -0500 Received: from STEVEPC (ob.relicore.com [192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i08075pu018303 for ; Wed, 7 Jan 2004 19:07:05 -0500 (EST) From: "Steve Gonczi" To: Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 19:27:22 -0500 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.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <7C2561A2-416C-11D8-96D1-000A95D9C74C@nominum.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 Typically, multiple interfaces are useful for load balancing, or HA (High Availability). The main problem that I see with the draft, that it appears to mandate policy. I.e. "henceforth, yer machine shall not have multiple active interfaces connected to the same wire" IMHO it would be more useful to generate your proposed permanent client id's on a per interface basis, and allow the DHC server to assign separate IP-s to them. As to handling DNS, it seems to make sense to me to generate multiple A records. This would result in DNS round-robin, which is a quite reasonable behavior in case of multiple ips under a common name. (Be they on the same network, or different ones) It is fairly common to have a machine connected to multiple networks. If you wish to reach this machine via a single DNS name, you run into the same DNS issue that you were originally describing. There are only 2 ways I can think of to get around the DNS issue: Assign different DNS names for each leg ( interface) of the machine, or assign multiple A records, hence round robin. /sG > No, they'll both get the same IP address. Can you explain why it's > useful to have two interfaces attached to the same wire with different > IP addresses acquired through DHCP? I should point out that if you > want to have two separate identities, you should generate two separate > identities, and this is actually orthogonal to the question of whether > you have more than one interface. _______________________________________________ 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 Jan 7 20:37:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17497; Wed, 7 Jan 2004 20:37:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeP6d-0006ma-1C; Wed, 07 Jan 2004 20:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeP6A-0006lL-VX for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 20:36: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 UAA17490 for ; Wed, 7 Jan 2004 20:36:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeP65-0005jR-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 20:36:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeP4Q-0005dG-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 20:34:47 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AeP37-0005UD-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 20:33:25 -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 i081WW57064190; Wed, 7 Jan 2004 20:32:40 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" Cc: Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 20:32:38 -0500 Message-ID: <000001c3d587$5045d180$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: 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 OK, if your intention is for this to be REQUIRED, I think you need to = make that clearer much earlier in the document. The abstract mentions nothing about making this REQUIRED and replacing = the existing client identifier scheme. The introduction is better at making = this clear now that I re-read it, though it isn't clear that you want all = clients to use this as all it says is: DHCPv4 client implementations that conform to this specification use a DHCPv6-style DHCP Unique Identifier (DUID) encapsulated in a DHCPv4 client identifier option. This supersedes the behaviour specified in RFC2131 and RFC2132." With the IANA changes, you're really saying that no new old-style client identifiers may be created and that needs to be stated much earlier. Also, section 1.0 only has SHOULDs which, to me, conflicts with the IANA statements. What about DHCPv4 clients that never expect to implement = IPv6? Sorry to be so difficult about this. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com]=20 Sent: Wednesday, January 07, 2004 6:56 PM To: Bernie Volz Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Request for review of 3315id draft... On Jan 7, 2004, at 3:43 PM, Bernie Volz wrote: > But I also think we should allow for a new hardware type to come along > and be used with DHCP clients that might want to use the existing=20 > format? > So, I'd rather you just say 255 is for the DUID and leave it at that? It certainly wasn't my intention that following this document should be=20 optional, except in the sense that clients that haven't been upgraded=20 still need to be supported. The way client identifiers are currently=20 being done is broken. This document is a proposal to fix it. Part=20 of fixing it is that the old way of doing it is deprecated. Adding=20 new identifier types would be a mistake, IMHO. If you want to add a=20 new identifier type, add a new 3315-style DUID. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 7 20:41:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17651; Wed, 7 Jan 2004 20:41: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 1AePAU-0007Du-Ra; Wed, 07 Jan 2004 20: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 1AePA9-0007DH-DN for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 20:40: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 UAA17622 for ; Wed, 7 Jan 2004 20:40:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AePA7-0005uv-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 20:40:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeP80-0005q2-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 20:38:29 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AeP7a-0005lL-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 20:38:02 -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 i081brGn056648; Wed, 7 Jan 2004 20:38:02 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" Cc: Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Wed, 7 Jan 2004 20:38:00 -0500 Message-ID: <000101c3d588$0ff997f0$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: <6B484624-416D-11D8-96D1-000A95D9C74C@fugue.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: 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 OK. I re-read the text and I do think you've written enough on the issue. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@fugue.com] Sent: Wednesday, January 07, 2004 6:59 PM To: Bernie Volz Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Request for review of 3315id draft... On Jan 7, 2004, at 3:43 PM, Bernie Volz wrote: > BV> Yeah, I'd like to avoid the Interface Identifier as well!!! I > think you > need to point out the impact so that people that want to switch to > using the > DUID take this into account. I don't see the value in adding any more text here. Do you have a proposal for what you want added? The text already points out that the client has to handle this case. I don't want to specify how the client handles it, just that it has to handle it. Otherwise we're opening a really big can of worms. I think anybody serious implementor is going to have to wrestle with how to deal with this. Maybe when they have some implementation experience *they* can write it up. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 8 04:37:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14455; Thu, 8 Jan 2004 04:37: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 1AeWb7-0004To-QJ; Thu, 08 Jan 2004 04:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeWaZ-0004RN-1T for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 04:36: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 EAA14421 for ; Thu, 8 Jan 2004 04:36:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeWaW-0004pZ-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 04:36:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeWYe-0004km-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 04:34:29 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AeWX2-0004bL-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 04:32:48 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119169>; Thu, 8 Jan 2004 10:31:01 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Thu, 8 Jan 2004 10:30:38 +0100 Message-ID: From: "Rentschler, Markus" To: dhcwg@ietf.org Subject: AW: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 10:30:37 +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 Hi Vasu, Your suggestion with the interface index added to the client identifier = is basically the same mechanism as described in my draft , with the difference that = you want to add the interface information to the client identifier option instead of using an own option for that information. - Markus > -----Urspr=FCngliche Nachricht----- > Von: Vasu, Vallabhaneni [SMTP:vasu@austin.ibm.com] > Gesendet am: Donnerstag, 8. Januar 2004 00:33 > An: Kostur, Andre > Cc: Ted Lemon; dhcwg@ietf.org > Betreff: Re: [dhcwg] Request for review of 3315id draft... >=20 > Correct me if I am wrong. >=20 > I thought as per RFC 3315 a system is supposed to have only one DUID. >=20 > The reason I suggested using interface index asI know of many = customers > who have systems with two interface on the same subnet. Now with this > change one of the interface will not get IP address. >=20 > Thanks > Vasu Vallabhaneni >=20 >=20 >=20 > "Kostur, Andre" wrote: >=20 > > Part 1.1Type: Plain Text (text/plain) >=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 Jan 8 07:44:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20759; Thu, 8 Jan 2004 07:44: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 1AeZW4-00050b-W1; Thu, 08 Jan 2004 07:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMsy-0008Pk-K7 for dhcwg@optimus.ietf.org; Wed, 07 Jan 2004 18:14: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 SAA12613 for ; Wed, 7 Jan 2004 18:14:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMso-0007Ed-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:14:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMqZ-0007A0-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:12:20 -0500 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx with smtp (Exim 4.12) id 1AeMpH-00075w-00 for dhcwg@ietf.org; Wed, 07 Jan 2004 18:10:59 -0500 Received: (qmail 12248 invoked by uid 65534); 7 Jan 2004 23:10:28 -0000 Received: from p5091AE53.dip.t-dialin.net (EHLO kayak500) (80.145.174.83) by mail.gmx.net (mp012) with SMTP; 08 Jan 2004 00:10:28 +0100 X-Authenticated: #4846771 From: "Rainer R. Friedrich" To: dhcwg@ietf.org Date: Thu, 08 Jan 2004 00:10:45 +0100 MIME-Version: 1.0 Subject: [dhcwg] Accept as WG Message-ID: <3FFCA005.14371.156B08@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body 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 Hello, I support this draft. Sincerely Rainer R. Friedrich _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 8 11:11:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00303; Thu, 8 Jan 2004 11:11: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 1AeckQ-0000Bl-1k; Thu, 08 Jan 2004 11: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 1Aeck9-00009y-FS for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 11:10: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 LAA00164 for ; Thu, 8 Jan 2004 11:10:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeck6-0004Xu-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 11:10:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeciF-0004NZ-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 11:08:48 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AecgN-0004GF-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 11:06:51 -0500 Received: from [10.59.1.9] (adsl-67-113-22-114.dsl.snfc21.pacbell.net [67.113.22.114]) by toccata.fugue.com (Postfix) with ESMTP id C9CD71B200C; Thu, 8 Jan 2004 10:01:22 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 08:06:48 -0800 To: "Steve Gonczi" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 7, 2004, at 4:27 PM, Steve Gonczi wrote: > Typically, multiple interfaces are useful for > load balancing, or HA (High Availability). I can't see why you'd use DHCP to configure a high availability port. However, I agree that mandating policy is the wrong idea. I'm just unsure how to not mandate policy. I think maybe placing the burden on the client to do the right thing is, if you will, the right thing. I'm thinking of adding a section that explains these issues in some detail, and suggesting that clients that want to have multiple identities on the same wire have to use different client identifiers, but should use 3315-style identifiers. Clients that want this functionality also need to handle naming sensibly. I don't think we can place a requirement on the server that it mediate multiple A records on the same domain name, if only because there is no guarantee that you are talking to the same DHCP server out both ports. The problem with this approach is that you're not supposed to have to configure a DHCP client - it's just supposed to do the right thing. How does the DHCP client know whether two interfaces means high availability or alternate media? I can think of ways to guess, or we could suggest that there be a UI feature to determine this, I suppose. I really didn't want to go down this rathole, but I see that in a sense I've painted myself into a corner. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 8 11:16:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00591; Thu, 8 Jan 2004 11:16: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 1AecpF-0000MZ-QO; Thu, 08 Jan 2004 11:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aecoe-0000Lp-NU for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 11:15: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 LAA00569 for ; Thu, 8 Jan 2004 11:15:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecoY-00056A-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 11:15:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aecln-0004o6-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 11:12:28 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Aecjq-0004VB-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 11:10:26 -0500 Received: from [10.59.1.9] (adsl-67-113-22-114.dsl.snfc21.pacbell.net [67.113.22.114]) by toccata.fugue.com (Postfix) with ESMTP id 379681B200C; Thu, 8 Jan 2004 10:04:59 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2B097944-41F5-11D8-A07E-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 08:10:25 -0800 To: "Steve Gonczi" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hm, one other approach would be to use an interface identification field in the client identifier as Vasu suggested, but give the server the *option* of treating two DUIDs with different interface IDs on the same wire as different clients or as the same client. This places the configuration control in the server, where it's more likely to be done correctly. The client still has to be prepared to get the same IP address on two interfaces, though. This adds complexity to the DHCP server, obviously. Comments? Would everybody just treat DUID+IID as an opaque identifier anyway? This does have the advantage of being easier to specify... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 8 14:25:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06956; Thu, 8 Jan 2004 14:25: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 1AefmA-0000im-0N; Thu, 08 Jan 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 1Aeflr-0000gh-2E for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 14:24: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 OAA06937 for ; Thu, 8 Jan 2004 14:24:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeflo-0000mm-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 14:24:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aefk3-0000gQ-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 14:22:52 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1Aefip-0000YV-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 14:21:35 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i08JKurE304218; Thu, 8 Jan 2004 14:20:56 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i08JKtkC088700; Thu, 8 Jan 2004 12:20:56 -0700 Received: from login-2.austin.ibm.com (login-2.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id i08JKs1Z071666; Thu, 8 Jan 2004 13:20:54 -0600 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by login-2.austin.ibm.com (AIX4.3/8.9.3p2/8.7-client1.01) with ESMTP id NAA56644; Thu, 8 Jan 2004 13:17:56 -0600 Message-ID: <3FFDAD94.EDE06BF3@austin.ibm.com> Date: Thu, 08 Jan 2004 13:20:52 -0600 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: Ted Lemon CC: Steve Gonczi , dhcwg@ietf.org Subject: Re: [dhcwg] Request for review of 3315id draft... References: <2B097944-41F5-11D8-A07E-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=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 Ted Lemon wrote: > Hm, one other approach would be to use an interface identification > field in the client identifier as Vasu suggested, but give the server > the *option* of treating two DUIDs with different interface IDs on the > same wire as different clients or as the same client. This places the > configuration control in the server, where it's more likely to be done > correctly. The client still has to be prepared to get the same IP > address on two interfaces, though. This adds complexity to the DHCP > server, obviously. > > Comments? Would everybody just treat DUID+IID as an opaque identifier > anyway? > I think the server should use it as opaque identifier. But when updating DNS the dhcp sever can check for all the client records which have matching DUID and then add new info as aliases to the existing names. Say the dhcp server has given the following address DUID - 1 client1 10.10.10.1 If the client requests IP address for another interface with IID - 2 DUID - 2 client1 10.10.10.5 Then the dhcp server adds the second client1 IN A 10.10.10.1 10.10.10.5 similarly adds ptr records. In the above case host name is same so there is no problem. But if the hostname is different then dhcp can add it as an alias. Thanks Vasu > > This does have the advantage of being easier to specify... > > _______________________________________________ > 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 Jan 8 14:39:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07533; Thu, 8 Jan 2004 14:39: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 1Aefzh-00025W-JH; Thu, 08 Jan 2004 14: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 1AefzL-00023T-QM for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 14:38: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 OAA07486 for ; Thu, 8 Jan 2004 14:38:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AefzJ-0001Ve-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 14:38:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AefxV-0001PT-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 14:36:46 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Aefvg-0001JF-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 14:34:52 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 356921B20E6; Thu, 8 Jan 2004 13:29:19 -0600 (CST) In-Reply-To: <3FFDAD94.EDE06BF3@austin.ibm.com> References: <2B097944-41F5-11D8-A07E-000A95D9C74C@nominum.com> <3FFDAD94.EDE06BF3@austin.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 11:34:47 -0800 To: "Vasu, Vallabhaneni" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 8, 2004, at 11:20 AM, Vasu, Vallabhaneni wrote: > I think the server should use it as opaque identifier. But when > updating > DNS the dhcp sever can check for all the client records which have > matching DUID and then add new info as aliases to the existing names. Then it's not an opaque identifier, is it? In any case, remember the purpose of this draft: to make sure that resources associated with client identifiers are associated with the same client identifiers whether they were acquired using DHCPv4 or DHCPv6. So if we make DUID+IID opaque, then we haven't achieved our stated goal. If IID is going to be part of the client identifier, we have to say that the DUID+IID split is *not* opaque. > Say the dhcp server has given the following address > > DUID - 1 client1 10.10.10.1 > > If the client requests IP address for another interface with IID - 2 > > DUID - 2 client1 10.10.10.5 > > Then the dhcp server adds the second > > client1 IN A 10.10.10.1 > 10.10.10.5 There may be more than one DHCP server involved here. How do the two (or more!) DHCP servers decide to add additional A records, rather than deleting the old A record and adding the new one? PTR records are a non-issue, of course. > In the above case host name is same so there is no problem. But if the > hostname is different then dhcp can add it as an alias. Actually, it's the case where the hostname is different that there's no problem, because then you have one hostname per A record, and the current proposed DNS update system works. It is when you have two valid IP addresses and only one hostname that you run into problems. It is theoretically possible to modify the proposed DNS update system to support this, but I'm not at all sure that it's worth the effort. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 8 15:19:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10134; Thu, 8 Jan 2004 15:19: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 1AegcP-0004B2-8x; Thu, 08 Jan 2004 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegcI-0004Am-LX for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 15:18: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 PAA10091 for ; Thu, 8 Jan 2004 15:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegcH-0003Uj-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:18:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegaZ-0003Oz-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:17:07 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AegZZ-0003GH-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:16:05 -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 i08KFs57089262; Thu, 8 Jan 2004 15:16:04 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" , "'Vasu, Vallabhaneni'" Cc: Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 15:16:01 -0500 Message-ID: <000001c3d624$40f79540$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: 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 Also, if the client is the one that updates the A records, there's no problem since it knows what it wants to have happen? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, January 08, 2004 2:35 PM To: Vasu, Vallabhaneni Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Request for review of 3315id draft... On Jan 8, 2004, at 11:20 AM, Vasu, Vallabhaneni wrote: > I think the server should use it as opaque identifier. But when > updating > DNS the dhcp sever can check for all the client records which have > matching DUID and then add new info as aliases to the existing names. Then it's not an opaque identifier, is it? In any case, remember the purpose of this draft: to make sure that resources associated with client identifiers are associated with the same client identifiers whether they were acquired using DHCPv4 or DHCPv6. So if we make DUID+IID opaque, then we haven't achieved our stated goal. If IID is going to be part of the client identifier, we have to say that the DUID+IID split is *not* opaque. > Say the dhcp server has given the following address > > DUID - 1 client1 10.10.10.1 > > If the client requests IP address for another interface with IID - 2 > > DUID - 2 client1 10.10.10.5 > > Then the dhcp server adds the second > > client1 IN A 10.10.10.1 > 10.10.10.5 There may be more than one DHCP server involved here. How do the two (or more!) DHCP servers decide to add additional A records, rather than deleting the old A record and adding the new one? PTR records are a non-issue, of course. > In the above case host name is same so there is no problem. But if the > hostname is different then dhcp can add it as an alias. Actually, it's the case where the hostname is different that there's no problem, because then you have one hostname per A record, and the current proposed DNS update system works. It is when you have two valid IP addresses and only one hostname that you run into problems. It is theoretically possible to modify the proposed DNS update system to support this, but I'm not at all sure that it's worth the effort. _______________________________________________ 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 Jan 8 15:23:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10314; Thu, 8 Jan 2004 15:23: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 1AeggG-0004QV-Rn; Thu, 08 Jan 2004 15: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 1Aegfn-0004P9-Sy for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 15:22: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 PAA10256 for ; Thu, 8 Jan 2004 15:22:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aegfm-0003cr-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:22:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aegdt-0003Yx-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:20:34 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AegcL-0003VU-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:18:58 -0500 Received: from [81.200.65.115] (dhcp-115.wl.nominum.com [81.200.65.115]) by toccata.fugue.com (Postfix) with ESMTP id 544541B20E0; Thu, 8 Jan 2004 14:13:29 -0600 (CST) In-Reply-To: <000001c3d624$40f79540$6401a8c0@BVolz> References: <000001c3d624$40f79540$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Vasu, Vallabhaneni'" , , "'Ted Lemon'" From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 12:18:56 -0800 To: "Bernie Volz" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 8, 2004, at 12:16 PM, Bernie Volz wrote: > Also, if the client is the one that updates the A records, there's no > problem since it knows what it wants to have happen? Theoretically yes, but in practice I think it might actually be quite challenging to write a client that always does the right thing, or even that can be configured to always do the right thing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 8 15:47:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11456; Thu, 8 Jan 2004 15:47: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 1Aeh3U-0005Yf-9F; Thu, 08 Jan 2004 15:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeh3I-0005Y5-Kz for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 15: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 PAA11447 for ; Thu, 8 Jan 2004 15:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeh3H-0005Dx-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeh1d-00057O-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:45:06 -0500 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1Aeh0m-0004y3-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 15:44:12 -0500 Received: from STEVEPC (ob.relicore.com [192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i08KMppu019600 for ; Thu, 8 Jan 2004 15:22:54 -0500 (EST) From: "Steve Gonczi" To: Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 15:43:07 -0500 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.2416 (9.0.2911.0) 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=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 am begginnig to think this is a non-issue. Given multiple ip-s per DNS name: A) The client is be allowed to present one identity (say, ID1) for more than one interfaces. This would result in enforcing a "one active interface at a time" behavior. In a multi-server case, if a client tries to renew an IP address that a server has no pool (or knowledge) of, the client gets NAK-d, and gets a new address. This results in the A record being overwritten both in case of solitary, or multiple DHCP servers. B) OTOH, a client is allowed to present a separate identity (say, ID1, ID2) for each interface. This would result in multiple A records being maintained by either a solitary, or multiple DHCP servers. The A record for ID1 gets created or deleted as ID1 acquires or releases the IP, and the same happens for ID2. In reality, (B) can not be distinguished from a DNS round-robin server farm, where multiple IP addreses, located on multiple, separate servers are mapped to the same name via multiple A records. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 8 16:17:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12326; Thu, 8 Jan 2004 16: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 1AehWX-0006rS-22; Thu, 08 Jan 2004 16: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 1AehW5-0006pt-4x for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 16:16:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12307 for ; Thu, 8 Jan 2004 16:16:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AehVt-0006lg-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 16:16:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AehTA-0006a0-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 16:13:32 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AehM8-0006DN-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 16:06:16 -0500 Received: from [81.200.65.85] (dhcp-85.wl.nominum.com [81.200.65.85]) by toccata.fugue.com (Postfix) with ESMTP id D8E901B200C; Thu, 8 Jan 2004 15:00:19 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D318406-421E-11D8-98A2-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 13:05:45 -0800 To: "Steve Gonczi" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 8, 2004, at 12:43 PM, Steve Gonczi wrote: Be careful, Steve. I think you're conflating the client identifier and the client hostname, and they're two separate things. If the client sends a different ID and a different hostname on each interface, there's no problem. If it sends the same ID and hostname on each interface, there may be a problem. If it sends different ID and the same hostname on each interface, there's a problem. This would all be greatly simplified by simply requiring that the client do its own update, but we really aren't in a position to do that. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 8 17:26:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14788; Thu, 8 Jan 2004 17: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 1AeibI-0001CJ-Iz; Thu, 08 Jan 2004 17:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeiaq-00018Z-3V for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 17:25: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 RAA14647 for ; Thu, 8 Jan 2004 17:25:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeiab-00037h-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:25:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeiYh-0002qo-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:23:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeiTi-0002LF-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:18:10 -0500 Received: from pan.gwi.net ([207.5.128.165]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeiHp-0008ME-Hm for dhcwg@ietf.org; Thu, 08 Jan 2004 17:05: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 i08M55Gn077337; Thu, 8 Jan 2004 17:05:09 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" Cc: "'Vasu, Vallabhaneni'" , Subject: RE: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 17:05:14 -0500 Message-ID: <000101c3d633$7e467a10$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 Well, why don't we just do what we do for DHCPv6 ... add an IA (Identity Association) Option. That way, if the client has two interfaces, it can either chose to use two different IAs or none (in which case it may well = get the same address). This doesn't fully solve the DNS issue, but at least it gives the server = a hint that if an IA was sent, it might not be wise for the server to wipe = out other A records that the client has (since another server may have = assigned the client a different address). The DHCP server can always look at the = A record(s) and if the target address is within its authority, it can = delete the old A record (assuming the client does not have a valid lease for = the address). (Note that this also has the nice feature of allowing a client to get multiple addresses if it indeed wanted to even on a single interface - = why it would ever want to do this is beyond me, but ... It's also much = better than having multiple identifiers for the client, which is what would = happen today.) - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted Lemon Sent: Thursday, January 08, 2004 3:19 PM To: Bernie Volz Cc: 'Vasu, Vallabhaneni'; dhcwg@ietf.org; 'Ted Lemon' Subject: Re: [dhcwg] Request for review of 3315id draft... On Jan 8, 2004, at 12:16 PM, Bernie Volz wrote: > Also, if the client is the one that updates the A records, there's no > problem since it knows what it wants to have happen? Theoretically yes, but in practice I think it might actually be quite=20 challenging to write a client that always does the right thing, or even=20 that can be configured to always do the right thing. _______________________________________________ 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 Jan 8 17:43:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15623; Thu, 8 Jan 2004 17: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 1Aeirk-00029w-Kw; Thu, 08 Jan 2004 17:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeirX-00029N-Bi for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 17:42: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 RAA15602 for ; Thu, 8 Jan 2004 17:42:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeirU-0004KR-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:42:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeipa-0004ER-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:40:47 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Aeinz-00048D-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:39:08 -0500 Received: from [81.200.65.85] (dhcp-85.wl.nominum.com [81.200.65.85]) by toccata.fugue.com (Postfix) with ESMTP id D744C1B200C; Thu, 8 Jan 2004 16:33:37 -0600 (CST) In-Reply-To: <000101c3d633$7e467a10$6401a8c0@BVolz> References: <000101c3d633$7e467a10$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7782F257-422B-11D8-98A2-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "" From: Ted Lemon Subject: Re: [dhcwg] Request for review of 3315id draft... Date: Thu, 8 Jan 2004 14:39:06 -0800 To: "Bernie Volz" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 8, 2004, at 2:05 PM, Bernie Volz wrote: > Well, why don't we just do what we do for DHCPv6 ... add an IA > (Identity > Association) Option. That way, if the client has two interfaces, it can > either chose to use two different IAs or none (in which case it may > well get > the same address). Hm, good point - letting the client decide whether or not to use two IAs for two interfaces probably produces the right result. > This doesn't fully solve the DNS issue, but at least it gives the > server a > hint that if an IA was sent, it might not be wise for the server to > wipe out > other A records that the client has (since another server may have > assigned > the client a different address). The DHCP server can always look at > the A > record(s) and if the target address is within its authority, it can > delete > the old A record (assuming the client does not have a valid lease for > the > address). I think that an ad-hoc implementation like this is more likely to cause harm than good - it's really easy to imagine algorithms for doing this, and it's equally easy to imagine cases in which they would produce exactly the wrong results. If we think it's important to handle these cases, we should define a system that supports it. This is doable - we just need more TXT records, but that's easy. You'd have a TXT record indicating which node owned the name, and then another TXT record indicating which IP address goes with which individual IA. The problem with this is that it's a lot of complexity for little benefit. Generally speaking, I would expect that even when a client has multiple interfaces, advertising multiple A records for it on the same name is not going to produce the result that the user actually wants. It would probably be better to just have a system on the client for deciding which interface is primary, and setting the name on that one. Apple has such a system now, although I do not know how well it works, nor whether they use it in deciding for which interface to request that an A record be installed. In general, I think that when you want to advertise A records on multiple interfaces, you probably want the client to do the update so that it can be customized according to the client's wishes. > (Note that this also has the nice feature of allowing a client to get > multiple addresses if it indeed wanted to even on a single interface - > why > it would ever want to do this is beyond me, but ... It's also much > better > than having multiple identifiers for the client, which is what would > happen > today.) Yup, this is a win. Maybe it's better to just specify the slightly more complex solution. Does anybody but Bernie want to vote on this? I get the impression that Vasu is in favor of doing it this way, and possibly the folks in favor of the rentschler interface id draft would be satisfied by this approach as well? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailman-admin@ietf.org Fri Jan 9 13:00:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18795 for ; Fri, 9 Jan 2004 13:00:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0vP-00028H-3K for DHC-ARCHIVE@lists.ietf.org; Fri, 09 Jan 2004 12:59:59 -0500 Date: Fri, 09 Jan 2004 12:59:59 -0500 Message-ID: <20040109175959.9164.99498.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 qespress@bol.com.br Sat Jan 10 07:58:08 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 HAA04227 for ; Sat, 10 Jan 2004 07:58:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfIgs-00065P-00 for dhc-archive@ietf.org; Sat, 10 Jan 2004 07:58:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfIf5-00061x-00 for dhc-archive@ietf.org; Sat, 10 Jan 2004 07:56:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AfIdn-0005yP-00; Sat, 10 Jan 2004 07:55:00 -0500 Received: from [61.236.238.72] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1AfIdd-0004ug-7y; Sat, 10 Jan 2004 07:54:56 -0500 From: "Temas Patrulhados" To: dccp-request@ietf.org Subject: Lindenberg e o Clero "sem-microfone" ref.: phg 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: Sat, 10 Jan 2004 07:54:56 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES autolearn=no version=2.60

Ref.: gdz FreeAutomaticTranslator / TraductorGratuito / Retirar / SubscreverGratuitamente

Série Temas "Patrulhados" (2)

Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone

"Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na sua agenda o fim do boicote contra os sacerdotes sem-microfone?"

Adolpho Lindenberg

O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), incitando as invasões de terras promovidas pelo MST, criticando indiscriminadamente a Área de Livre Comércio das Américas (ALCA), as privatizações, as multinacionais (as norte-americanas, em especial), e o plantio dos transgênicos, apresenta um inconveniente sério: tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados.

Movimentos contestatários

É contristador perceber que na vasta rede de movimentos contestatários que está sendo articulada por todo o país, a ala progressista religiosa - fruto das Comunidades de Base e da Comissão Pastoral da Terra (CPT) - se sobressai como o núcleo mais ativo e radical em suas convicções. Para esses movimentos de contestação é de fundamental importância dar a impressão de que expressam a opinião majoritária, ou pelo menos muito expressiva, do Episcopado e no Clero.

Não é verdade, necessariamente.

Uma minoria do Clero fala, a maioria está calada

A realidade profunda é bem outra. A maioria do Episcopado e do Clero, na realidade, não tem voz nem vez na grande mídia. Suas pastorais, sermões e opiniões não chegam ao grande público. Quase ninguém os conhece, só alguns paroquianos e amigos próximos, com quem compartilham confidências. Eles são os prelados e sacerdotes sem-microfone; pertencem à imensa maioria dos excluídos dos grandes meios de difusão. E muitos deles inteligentes, cultos, de expressão fácil, com reflexões que ajudariam muito à autêntica formação da opinião nacional. Até por exigência de equilíbrio na ponderação das opiniões e de equidade em relação a este setor social, eles também precisariam ser ouvidos.

Padres sem-microfone são discriminados

O grande número dos padres sem-microfone, muitas vezes, talvez na maioria esmagadora dos casos, teria reservas sérias com as invasões e depredações das propriedades agrícolas. Mas são discriminados, não são ouvidos pelo público. De nada adiantam suas advertências. Não repercutem. Estão excluídos. Para eles, não funciona a encenação publicitária aparatosa, suas opiniões são ignoradas pela grande imprensa, o que acontece por exemplo no caso de "O Grito dos Excluídos". É que, para azar deles, nem estão entre os promotores da revolução social, nem pertencem aos pequenos grupos dos privilegiados pela mídia.

Excluir a exclusão

É preciso que se inclua entre os formadores de opinião, com acesso à mídia, também os prelados e sacerdotes que hoje estão sem microfone. Por que deixá-los de fora? Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na agenda já tão abrangente do "Grito dos Excluídos" também o fim do boicote contra os sacerdotes sem-microfone? Afinal de contas, não se proclamam os seus participantes em batalha contra as exclusões, pelo fim das discriminações? Ou é que umas exclusões podem existir, e são bem-vindas, e outras não? Se for assim afastam-se do que deseja o povo, pois milhões de brasileiros querem saber o que pensa o Clero sem-microfone.

Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado".

LINKS:

Lindenberg:Concordo (envie seu voto virtual, e, melhor ainda, acrescente seu comentário, caso desejar)

Lindenberg:Discordo (idem)

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

LINKS PARA RECEBER ARTIGOS GRATUITOS:

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

GratuitamenteArtigosAnteriores / GratuitamenteProximosArtigos / GratuitamenteTodosOsArtigos

LINKS PARA ADQUIRIR O LIVRO

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

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

LINK DE REMOÇÃO

ConstruNews:Remover

LINK PARA TOMAR CONTATO COM LINDENBERG

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

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

 From dhcwg-admin@ietf.org Wed Jan 14 15:54:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11237; Wed, 14 Jan 2004 15:54: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 1Ags1Z-0007VV-RV; Wed, 14 Jan 2004 15: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 1Ags1U-0007V5-IG for dhcwg@optimus.ietf.org; Wed, 14 Jan 2004 15:53:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11097; Wed, 14 Jan 2004 15:53:53 -0500 (EST) Message-Id: <200401142053.PAA11097@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, 14 Jan 2004 15:53:53 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-stateless-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 : Stateless DHCP Service for IPv6 Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-stateless-04.txt Pages : 10 Date : 2004-1-14 Stateless DHCPv6 service is used by nodes to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-stateless-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-stateless-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-1-14161423.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-stateless-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-stateless-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-14161423.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From lwenews@mail.com Sat Jan 17 02:31:08 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 CAA29544 for ; Sat, 17 Jan 2004 02:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhkvD-0002eN-00 for dhc-archive@ietf.org; Sat, 17 Jan 2004 02:31:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahku7-0002SK-00 for dhc-archive@ietf.org; Sat, 17 Jan 2004 02:30:00 -0500 Received: from adsl-64-218-142-244.dsl.rcsntx.swbell.net ([64.218.142.244] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1Ahktc-0002PH-00; Sat, 17 Jan 2004 02:29:28 -0500 From: "Memorial Cubano:" To: dccp-request@ietf.org Subject: Pedem Missas e orações pelas vítimas do comunismo ref.: tyr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 17 Jan 2004 02:29:28 -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.2 required=5.0 tests=FORGED_MUA_EUDORA,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.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora

Ref.: (eoj) InEnglish / InItaliano / EnCastellano

Memorial cubano: Pedido de Missas e orações pelas vítimas do comunismo

A ajuda urgente que solicitamos é de caráter estritamente espiritual, ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus

Queridos irmãos luso-brasileiros,

* Precisamos de vossa valiosa ajuda para resgatar do esquecimento a mais de 10 mil cubanos que morreram vítimas do regime comunista, sobre os quais se possui informação documentada. Esta ajuda que lhes solicitamos é de caráter estritamente espiritual, inteiramente ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus!

* Entre os dias 20 e 23 de fevereiro próximo, no Tamiami Park de Miami, Flórida, voluntários de diversos países organizarão o Memorial Cubano, consistente em mais de 10 mil cruzes brancas, cada uma delas tendo inscrito o nome de uma vítima do regime comunista de Cuba. Familiares desterrados que nunca puderam dar o adeus a seus seres queridos assassinados, por não ser-lhes permitido visitar suas tumbas em Cuba, poderão fazê-lo agora.

* No centro da área se localizará uma cruz de madeira gigante, também pintada de branco, denominada "Cruz da vítima desconhecida", que constituirá o reconhecimento a todos os que morreram por causa do regime comunista, porém a respeito dos quais até o momento não se possui informação suficiente.

* De que maneira vocês podem unir-se a esta cruzada de orações e a esta homenagem espiritual? Simplesmente encomendando uma Missa ou serviço religioso, organizando com sua família, comunidade ou colegas de trabalho um momento de oração conjunta, ou rezando privadamente. Solicitamos-lhes que as Missas sejam encomendadas, se for possível, para o domingo 22 de fevereiro. Assim, no mundo inteiro, nesse dia se elevarão preces a Deus pelo eterno descanso dessas almas. Poderão encomendá-las em benefício das "vítimas do genocídio cubano sob o regime comunista de Fidel Castro".

* Muitas destas vítimas foram jovens que enfrentaram o "paredón" de fuzilamento proclamando "Viva Cristo Rei!"

* Confirmem-nos o quanto antes vossa adesão, encomendando Missas, prometendo orações, etc., fazendo clic em:

ConfirmamosMissa/ServicoReligioso e/ou ConfirmamosOraçoesPreces incluindo local, data e, se o desejarem, outros detalhes.

* Irmãos ibero-americanos e homens e mulheres de boa vontade, de outras regiões do mundo, que leiam esta mensagem e a ela adiram: que a Providência os recompense com o cêntuplo já nesta terra!

Com a maior consideração e estima,

Renato Gómez - Coordenador Geral

Comitê Organizador do Memorial Cubano

Tel. (1-786) 621-7505 Miami (FL) www memorialcubano org

PS.:

Em vossas orações e preces incluam também os homens, mulheres e crianças que morreram afogados no estreito da Flórida, tentando alcançar a liberdade. Seus nomes são em sua maioria desconhecidos e fontes autorizadas estimam que o número deles seja de muitas dezenas de milhares de cubanos.

Por fim, rezem pelos presos políticos que agonizam nos cárceres, como o médico Oscar Elias Biscet, pela economista Martha Beatriz Roque e milhares de outros irmãos cubanos detidos DesejoInfoPresosPoliticos. A seis anos da viagem de S.S. João Paulo II a Cuba (21-25 de janeiro de 1998), se continua contrariando o sonho papal de que a ilha-cárcere abra-se ao mundo.

LINKS PRIORITÁRIOS:

ConfirmoMissa/ServiçoReligioso e/ou ConfirmoOraçoesPreces (incluindo nome, cidade e, se desejar, outros detalhes)

MinhaAjuda (narre de que maneira poderá ajudar-nos a difundir esta iniciativa espiritual e humanitária: reenviando esta notícia a seus amigos, levando-a a jornalistas conhecidos, colocando-a no quadro de avisos de seu local de trabalho, etc.; pode incluir também sugestões).

MinhaOpiniao

OUTROS LINKS:

DesejoRecibirLinkMemorialCubano (para receber o link do web site sobre o Memorial Cubano, com nomes de todas as vítimas)

DesejoReceberInfoPresosPoliticos

ProximosEnvios:SoloEnEspañol

NextMails:OnlyInEnglish

Remover

A difusão deste e-mail é de exclusiva responsabilidade da agência humanitária Derechos Sin Fronteras (DSF).

Tradução: Graça Salgueiro

 

 

From dhcwg-admin@ietf.org Mon Jan 19 10:34:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21471; Mon, 19 Jan 2004 10:34: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 1AibPd-0007ay-Ke; Mon, 19 Jan 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 1AibPY-0007XY-6h for dhcwg@optimus.ietf.org; Mon, 19 Jan 2004 10:33:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21290; Mon, 19 Jan 2004 10:33:51 -0500 (EST) Message-Id: <200401191533.KAA21290@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, 19 Jan 2004 10:33:51 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subscriber-id-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Subscriber ID Suboption for the DHCP Relay Agent Option Author(s) : R. Johnson, R. Droms Filename : draft-ietf-dhc-subscriber-id-05.txt Pages : 9 Date : 2004-1-16 This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable 'Subscriber-ID' with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-subscriber-id-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-subscriber-id-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-19105423.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subscriber-id-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subscriber-id-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-19105423.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 Jan 19 13:43:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01274; Mon, 19 Jan 2004 13: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 1AieMX-000303-P8; Mon, 19 Jan 2004 13: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 1AieMI-0002zV-5G for dhcwg@optimus.ietf.org; Mon, 19 Jan 2004 13:42:46 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01225 for ; Mon, 19 Jan 2004 13:42:43 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AieME-000538-4P; Mon, 19 Jan 2004 13:42:42 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 19 Jan 2004 13:42:42 -0500 Subject: [dhcwg] Last Call: 'The Authentication Suboption for the DHCP Relay Agent Option' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'The Authentication Suboption for the DHCP Relay Agent Option' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-02.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 20 10:48:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07033; Tue, 20 Jan 2004 10: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 1Aiy6j-0003Yx-55; Tue, 20 Jan 2004 10: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 1Aiy6B-0003Vr-Et for dhcwg@optimus.ietf.org; Tue, 20 Jan 2004 10:47:27 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06918 for ; Tue, 20 Jan 2004 10:47:23 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1Aiy53-0001nE-7m; Tue, 20 Jan 2004 10:46:17 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Tue, 20 Jan 2004 10:46:17 -0500 Subject: [dhcwg] Last Call: 'DHCP Subscriber ID Suboption for the DHCP Relay Agent Option' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'DHCP Subscriber ID Suboption for the DHCP Relay Agent Option' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-05.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 20 11:29:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09817; Tue, 20 Jan 2004 11:29: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 1AiykQ-0006Po-3j; Tue, 20 Jan 2004 11: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 1Aiyk6-0006PS-1R for dhcwg@optimus.ietf.org; Tue, 20 Jan 2004 11:28:42 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09769 for ; Tue, 20 Jan 2004 11:28:39 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1Aiyhk-0006XT-89; Tue, 20 Jan 2004 11:26:16 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Tue, 20 Jan 2004 11:26:16 -0500 Subject: [dhcwg] Protocol Action: 'Stateless DHCP Service for IPv6' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved the following document: - 'Stateless DHCP Service for IPv6 ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This document is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. Stateless DHCPv6 service is used by nodes to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. Working Group Summary This document is a product of the DHC WG. This document went through WG last call and was revised in response to WG last call comments. It was also revised to address IETF last call comments from Pekka Savola and Tim Chown. Protocol Quality The protocol defined in this document is a subset of the DHCPv6 specification, which is defined in RFC 3315, and there are already several implementations of RFC 3315. This document was reviewed for the IESG by Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 22 11:47:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28755; Thu, 22 Jan 2004 11: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 1Ajhyv-0004uc-36; Thu, 22 Jan 2004 11: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 1Ajhyi-0004tL-ND for dhcwg@optimus.ietf.org; Thu, 22 Jan 2004 11: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 LAA28629 for ; Thu, 22 Jan 2004 11:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajhyh-0004yR-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 11:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjhwS-0004S5-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 11:44:29 -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 1AjhsL-0003iZ-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 11:40:13 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Jan 2004 08:42:57 +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 i0MGdFKd015897; Thu, 22 Jan 2004 08:39: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 AFL48777; Thu, 22 Jan 2004 11:39:14 -0500 (EST) Message-Id: <4.3.2.7.2.20040122113702.0290c2e0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Jan 2004 11:39:10 -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 claims for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The WG should be aware of the following notice of IPR claims related to 'DHCP Subscriber ID Suboption for the DHCP Relay Agent Option' . The IPR claims are documented in http://www.ietf.org/ietf/IPR/PacketFront-IPR.txt - Ralph ------- Forwarded Message From: "Fredrik Nyman" To: iesg@ietf.org CC: matjon@packetfront.com Date: Thu, 22 Jan 2004 14:17:00 +0100 Subject: Re: [dhcwg] Last Call: 'DHCP Subscriber ID Suboption for the DHCP Relay Agent Option' to Proposed Standard Reply-to: fredrik@packetfront.com On 20 Jan 2004 at 10:46, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG to > consider the following document: > > - 'DHCP Subscriber ID Suboption for the DHCP Relay Agent Option' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-03. Please note that PacketFront has IPR claims related to this draft. If this draft becomes a proposed standard, please ensure that the appropriate notes are included in the final document. Thank you. -- Fredrik Nyman PacketFront Sweden AB http://www.packetfront.com/ ------- End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 22 12:26:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00260; Thu, 22 Jan 2004 12:26: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 1Ajiaf-00008n-Tq; Thu, 22 Jan 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 1AjiZo-00006W-0w for dhcwg@optimus.ietf.org; Thu, 22 Jan 2004 12:25: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 MAA00219 for ; Thu, 22 Jan 2004 12:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjiZc-00073N-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 12:24:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjiWg-0006tM-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 12:21:54 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AjiSt-0006gY-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 12:18:00 -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 450B01B226E; Thu, 22 Jan 2004 11:09:37 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040122113702.0290c2e0@flask.cisco.com> References: <4.3.2.7.2.20040122113702.0290c2e0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] IPR claims for Date: Thu, 22 Jan 2004 11:17:25 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is really unfortunate. I think the right thing to do at this point is for the WG to put these two drafts on hold (that is, remove them from consideration and put tombstones on them on the IETF FTP site) until this patent issue is resolved. Otherwise we're laying a trap for people who might be tempted to implement this and might later get sued by PacketFront for patent infringement. It would be interesting to hear what the folks at Cisco have to say about this. Sigh. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 22 13:09:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02086; Thu, 22 Jan 2004 13: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 1AjjGH-0004At-KA; Thu, 22 Jan 2004 13: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 1AjjFj-00043B-Vi for dhcwg@optimus.ietf.org; Thu, 22 Jan 2004 13:08: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 NAA02028 for ; Thu, 22 Jan 2004 13:08:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjFX-0001W0-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 13:08:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjDB-0001PM-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 13:05:49 -0500 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1AjjBn-0001Jc-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 13:04:23 -0500 Received: from STEVEPC ([192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i0MHgES5010030 for ; Thu, 22 Jan 2004 12:42:14 -0500 (EST) From: "Steve Gonczi" To: Subject: RE: [dhcwg] IPR claims for Date: Thu, 22 Jan 2004 13:03:20 -0500 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.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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=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 second Ted's motion. I find it especially troublesome that these claims are disclosed relatively late in the game. My personal preference would be not to put any time/effort into reviewing any draft with attached IPR claims. /sG PS. The opinions voiced here are mine. My employer has nothing to do with it. -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted Lemon Sent: Thursday, January 22, 2004 12:17 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] IPR claims for >This is really unfortunate. I think the right thing to do at this >point is for the WG to put these two drafts on hold (that is, remove >them from consideration and put tombstones on them on the IETF FTP >site) until this patent issue is resolved. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 22 13:48:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03603; Thu, 22 Jan 2004 13:48: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 1Ajjs1-0007Fj-RS; Thu, 22 Jan 2004 13:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajjr5-0007E5-05 for dhcwg@optimus.ietf.org; Thu, 22 Jan 2004 13:47: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 NAA03466 for ; Thu, 22 Jan 2004 13:47:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajjr2-0003SJ-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 13:47:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajjq7-0003Qx-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 13:46:04 -0500 Received: from chimera.incognito.com ([206.172.52.66] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1Ajjpt-0003PQ-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 13:45:49 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 1AjjpN-0004Vm-00 for ; Thu, 22 Jan 2004 10:45:17 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 10:45:11 -0800 Message-ID: From: "Kostur, Andre" To: dhcwg@ietf.org Subject: RE: [dhcwg] IPR claims for Date: Thu, 22 Jan 2004 10:45:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E117.DD058610" 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_01C3E117.DD058610 Content-Type: text/plain; charset="iso-8859-1" I'm curious. Their original notification was on April 17th.... and their notification is filled with "may obtain" and "to be filed in the future". To date, does anybody know if they have obtained and/or actually filed for the patents (and other IPR)? Also, have they mentioned what their reasonable and non-discriminatory licencing requirements are? > -----Original Message----- > From: Steve Gonczi [mailto:steve@relicore.com] > Sent: Thursday, January 22, 2004 10:03 AM > To: dhcwg@ietf.org > Subject: RE: [dhcwg] IPR claims for > > > > I second Ted's motion. > > I find it especially troublesome that these claims are disclosed > relatively late in the game. > > My personal preference would be not to put any time/effort into > reviewing any draft with attached IPR claims. > > /sG > > PS. The opinions voiced here are mine. > My employer has nothing to do with it. > > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On > Behalf Of Ted > Lemon > Sent: Thursday, January 22, 2004 12:17 PM > To: Ralph Droms > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] IPR claims for > > > > >This is really unfortunate. I think the right thing to do at this > >point is for the WG to put these two drafts on hold (that is, remove > >them from consideration and put tombstones on them on the IETF FTP > >site) until this patent issue is resolved. ------_=_NextPart_001_01C3E117.DD058610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] IPR claims for = <draft-ietf-dhc-subscriber-id-05.txt>

I'm curious.  Their original notification was on = April 17th.... and their notification is filled with "may = obtain" and "to be filed in the future".  To date, = does anybody know if they have obtained and/or actually filed for the = patents (and other IPR)?

Also, have they mentioned what their reasonable and = non-discriminatory licencing requirements are?

> -----Original Message-----
> From: Steve Gonczi [mailto:steve@relicore.com]=
> Sent: Thursday, January 22, 2004 10:03 = AM
> To: dhcwg@ietf.org
> Subject: RE: [dhcwg] IPR claims for
> = <draft-ietf-dhc-subscriber-id-05.txt>
>
>
> I second Ted's motion.
>
> I find it especially troublesome that these = claims are disclosed
> relatively late in the game.
>
> My personal preference would be not to put any = time/effort into
> reviewing any draft with attached IPR = claims.
>
> /sG
>
> PS. The opinions voiced here are mine.
> My employer has nothing to do with it.
>
>
> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On =
> Behalf Of Ted
> Lemon
> Sent: Thursday, January 22, 2004 12:17 = PM
> To: Ralph Droms
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] IPR claims for
> = <draft-ietf-dhc-subscriber-id-05.txt>
>
>
> >This is really unfortunate.   I = think the right thing to do at this
> >point is for the WG to put these two drafts = on hold (that is, remove
> >them from consideration and put tombstones = on them on the IETF FTP
> >site) until this patent issue is = resolved.

------_=_NextPart_001_01C3E117.DD058610-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 22 16:05:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11513; Thu, 22 Jan 2004 16:05: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 1Ajm0d-0001yE-H8; Thu, 22 Jan 2004 16: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 1Ajm0Z-0001xU-F9 for dhcwg@optimus.ietf.org; Thu, 22 Jan 2004 16:04: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 QAA11483 for ; Thu, 22 Jan 2004 16:04:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajm0S-0001Qi-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 16:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlwU-0001LV-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 16:00:47 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.104]) by ietf-mx with esmtp (Exim 4.12) id 1AjlvI-0001Gv-00 for dhcwg@ietf.org; Thu, 22 Jan 2004 15:59:33 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0MKwRvM675346; Thu, 22 Jan 2004 15:58:27 -0500 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0MKwRIF114976; Thu, 22 Jan 2004 15:58:27 -0500 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 i0MKvi8L021698; Thu, 22 Jan 2004 15:57:44 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i0MKviEC021694; Thu, 22 Jan 2004 15:57:44 -0500 Message-Id: <200401222057.i0MKviEC021694@rotala.raleigh.ibm.com> To: "Steve Gonczi" cc: dhcwg@ietf.org Subject: Re: [dhcwg] IPR claims for In-Reply-To: Message from steve@relicore.com of "Thu, 22 Jan 2004 13:03:20 EST." Date: Thu, 22 Jan 2004 15:57:44 -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.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 find it especially troublesome that these claims are disclosed > relatively late in the game. Technically, they were disclosed in April 2003 when the notice went up on the IETF Web page. Not sure if this is what you mean by "late". Clearly, the WG should have been notified as well, but that apparently didn't happen. Another process point that the disclosure doesn't address is what the licensing terms will be. Per 2026bis, the following should take place: (C) Where Intellectual Property Rights have been disclosed for IETF Documents as provided in Section 6 of this document, the IETF Executive Director shall request from the discloser of such IPR, a written assurance that upon approval by the IESG for publication as RFCs of the relevant IETF specification(s), all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to Implementing Technology under one of the licensing options specified in Section 6.5 below unless such a statement has already been submitted. The working group proposing the use of the technology with respect to which the Intellectual Property Rights are disclosed may assist the IETF Executive Director in this effort. The results of this procedure shall not, in themselves, block publication of an IETF Document or advancement of an IETF Document along the standards track. A working group may take into consideration the results of this procedure in evaluating the technology, and the IESG may defer approval when a delay may facilitate obtaining such assurances. The results will, however, be recorded by the IETF Executive Director, and be made available online. I do not know if the Secretariat has made such a request; I will go find out. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 23 07:47:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28311; Fri, 23 Jan 2004 07:47: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 1Ak0iD-0008Qg-8V; Fri, 23 Jan 2004 07: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 1Ak0hp-0008PC-Q7 for dhcwg@optimus.ietf.org; Fri, 23 Jan 2004 07:46: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 HAA28297 for ; Fri, 23 Jan 2004 07:46:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak0hp-0003Vp-00 for dhcwg@ietf.org; Fri, 23 Jan 2004 07:46:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak0gq-0003Uo-00 for dhcwg@ietf.org; Fri, 23 Jan 2004 07:45:36 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by ietf-mx with esmtp (Exim 4.12) id 1Ak0gA-0003U3-00 for dhcwg@ietf.org; Fri, 23 Jan 2004 07:44:55 -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 3919877 for dhcwg@ietf.org; Fri, 23 Jan 2004 13:44:52 +0100 From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: Subject: Re: [dhcwg] IPR claims for Date: Fri, 23 Jan 2004 13:56:34 +0100 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401231356.34094.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 Thursday 22 January 2004 19:03, Steve Gonczi wrote: > I second Ted's motion. So do we. - 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 Jan 23 15:59:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21964; Fri, 23 Jan 2004 15:59: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 1Ak8OL-0002NK-4F; Fri, 23 Jan 2004 15: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 1Ak8OG-0002N3-SH for dhcwg@optimus.ietf.org; Fri, 23 Jan 2004 15:58:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21837; Fri, 23 Jan 2004 15:58:53 -0500 (EST) Message-Id: <200401232058.PAA21837@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, 23 Jan 2004 15:58:53 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-reclassify-options-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 : Reclassifying DHCPv4 Options Author(s) : B. Volz Filename : draft-ietf-dhc-reclassify-options-00.txt Pages : 9 Date : 2004-1-23 This document revises RFC 2132 to reclassify DHCPv4 option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-reclassify-options-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-reclassify-options-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-reclassify-options-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-1-23161701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-reclassify-options-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-reclassify-options-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-23161701.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 Jan 23 19:16:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04445; Fri, 23 Jan 2004 19:16: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 1AkBSy-00021I-Uj; Fri, 23 Jan 2004 19: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 1AkBSx-00020h-6E for dhcwg@optimus.ietf.org; Fri, 23 Jan 2004 19:15: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 TAA04438 for ; Fri, 23 Jan 2004 19:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkBSv-000779-00 for dhcwg@ietf.org; Fri, 23 Jan 2004 19:15:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkBS3-000769-00 for dhcwg@ietf.org; Fri, 23 Jan 2004 19:15:04 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1AkBRi-00074d-00; Fri, 23 Jan 2004 19:14:42 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0O0Egk13988; Fri, 23 Jan 2004 16:14:42 -0800 (PST) Message-Id: <200401240014.i0O0Egk13988@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 23 Jan 2004 16:14:42 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-9.1 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [dhcwg] RFC 3679 on Unused Dynamic Host Configuration Protocol (DHCP) Option Codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3679 Title: Unused Dynamic Host Configuration Protocol (DHCP) Option Codes Author(s): R. Droms Status: Informational Date: January 2004 Mailbox: rdroms@cisco.com Pages: 8 Characters: 13804 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-unused-optioncodes-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3679.txt Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040123161306.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3679 --OtherAccess Content-Type: Message/External-body; name="rfc3679.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040123161306.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 24 12:32:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15424; Sat, 24 Jan 2004 12:32: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 1AkRdY-0001LP-QV; Sat, 24 Jan 2004 12: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 1AkRcv-0001L1-30 for dhcwg@optimus.ietf.org; Sat, 24 Jan 2004 12:31: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 MAA15414 for ; Sat, 24 Jan 2004 12:31:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkRcj-00004q-00 for dhcwg@ietf.org; Sat, 24 Jan 2004 12:31:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkRb7-00003Y-00 for dhcwg@ietf.org; Sat, 24 Jan 2004 12:29:29 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1AkRap-00002U-00 for dhcwg@ietf.org; Sat, 24 Jan 2004 12:29:11 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3F452277945; Sat, 24 Jan 2004 09:28:37 -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 09761-02; Sat, 24 Jan 2004 09:28:37 -0800 (PST) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 7F5D9277943; Sat, 24 Jan 2004 09:28:36 -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 JAA07830; Sat, 24 Jan 2004 09:28:36 -0800 (PST) Message-Id: <200401241728.JAA07830@redback.com> To: dhcwg@ietf.org Cc: naiming@redback.com, kishore@redback.com, souissal@redback.com, tom_soon@labs.sbc.com, phantom@kt.co.kr Date: Sat, 24 Jan 2004 09:28:36 -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 Subject: [dhcwg] Internet-Drafts@ietf.org: I-D ACTION:draft-shen-dhc-block-alloc-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 draft has been posted, please review and comment. The authors would like this draft to be adopted as a DHC working-group document. thanks. - Naiming ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shen-dhc-block-alloc-01.txt Date: Fri, 23 Jan 2004 15:59:26 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Proxy Server Micro-block Allocation Scheme For IP Address Pool Management Author(s) : N. Shen Filename : draft-shen-dhc-block-alloc-01.txt Pages : 8 Date : 2004-1-23 A new DHCP address allocation mechanism called Micro-blocking is proposed in this document. It is used for DHCP proxy servers or routers working with DHCP servers to maximize the IP address allocation efficiency while improve dynamic routing scalability in provider's networks. A DHCP sub-option within the relay agent information option 82 is defined in this document. This simple DHCP extension can be applied as a simple IP address-pool management among multiple IP devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shen-dhc-block-alloc-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 25 12:25:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11531; Sun, 25 Jan 2004 12:25: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 1Ako0M-0000LS-US; Sun, 25 Jan 2004 12: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 1Aknzl-0000Kl-2D for dhcwg@optimus.ietf.org; Sun, 25 Jan 2004 12:24:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11510 for ; Sun, 25 Jan 2004 12:24:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aknze-00013j-00 for dhcwg@ietf.org; Sun, 25 Jan 2004 12:24:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aknw3-0000xt-00 for dhcwg@ietf.org; Sun, 25 Jan 2004 12:20:36 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AknvX-0000sC-00 for dhcwg@ietf.org; Sun, 25 Jan 2004 12:20:03 -0500 Received: from jschnizl-w2k.cisco.com (sjc-vpn2-300.cisco.com [10.21.113.44]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0PHJ25l027554; Sun, 25 Jan 2004 09:19:03 -0800 (PST) Message-Id: <4.3.2.7.2.20040124180124.02052c98@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 25 Jan 2004 12:19:00 -0500 To: Naiming Shen From: John Schnizlein Subject: Re: [dhcwg] Internet-Drafts@ietf.org: I-D ACTION:draft-shen-dhc-block-alloc-01.txt Cc: dhcwg@ietf.org, naiming@redback.com, kishore@redback.com, souissal@redback.com, tom_soon@labs.sbc.com, phantom@kt.co.kr In-Reply-To: <200401241728.JAA07830@redback.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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.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 impression is that this document covers functionality similar the v4 prefix delegation already proposed in draft-ietf-dhc-subnet-alloc-00.txt. The biggest advantages of the subnet-alloc draft I can see are these: 1) Specifies the protocol features rather than the allocation behavior, 2) Avoids implications of the size of the allocated subnets, 3) Avoids unnecessary entanglements of DHCP with edge router functionality. 4) Avoids the unnecessary new component of "proxy DHCP server" John At 12:28 PM 1/24/2004, Naiming Shen wrote: >This draft has been posted, please review and comment. The authors >would like this draft to be adopted as a DHC working-group document. >... > >A new DHCP address allocation mechanism called Micro-blocking > is proposed in this document. It is used for DHCP proxy servers or > routers working with DHCP servers to maximize the IP address > allocation efficiency while improve dynamic routing scalability > in provider's networks. A DHCP sub-option within the relay agent > information option 82 is defined in this document. This simple > DHCP extension can be applied as a simple IP address-pool management > among multiple IP devices. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shen-dhc-block-alloc-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 26 02:38:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22969; Mon, 26 Jan 2004 02:38:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al1Jt-0005kh-NC; Mon, 26 Jan 2004 02:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al1Je-0005i6-H7 for dhcwg@optimus.ietf.org; Mon, 26 Jan 2004 02:37: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 CAA22940 for ; Mon, 26 Jan 2004 02:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al1Ja-0002n7-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 02:37:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al1Ic-0002kt-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 02:36:47 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1Al1IO-0002iu-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 02:36:32 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 14F8DA705D8; Sun, 25 Jan 2004 23:36:27 -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 05234-08; Sun, 25 Jan 2004 23:36:26 -0800 (PST) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 68F67A705D7; Sun, 25 Jan 2004 23:36:26 -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 XAA22315; Sun, 25 Jan 2004 23:36:26 -0800 (PST) Message-Id: <200401260736.XAA22315@redback.com> To: John Schnizlein Cc: Naiming Shen , dhcwg@ietf.org, kishore@redback.com, souissal@redback.com, tom_soon@labs.sbc.com, phantom@kt.co.kr Subject: Re: [dhcwg] Internet-Drafts@ietf.org: I-D ACTION:draft-shen-dhc-block-alloc-01.txt In-reply-to: Mail from John Schnizlein dated Sun, 25 Jan 2004 12:19:00 EST <4.3.2.7.2.20040124180124.02052c98@wells.cisco.com> Date: Sun, 25 Jan 2004 23:36:25 -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: , John, ]My impression is that this document covers functionality similar the v4 ]prefix delegation already proposed in draft-ietf-dhc-subnet-alloc-00.txt. In some sense, you can think of Micro-blocking draft as the competing proposal to draft-ietf-dhc-subnet-alloc-00.txt, but with a much simpler mechanism. ] ]The biggest advantages of the subnet-alloc draft I can see are these: ]1) Specifies the protocol features rather than the allocation behavior, I'm not sure I fully understand this point. If you are saying more protocol changes is always better, then I have reservation on this. ]2) Avoids implications of the size of the allocated subnets, The whole point of Micro-block mechanism is allow the address allocation to be controlled from a centralized server; which is needed for most efficient address allocation. This also much simplify the mechanism and implementation, as a side-effect it also does not require much protocol changes. ]3) Avoids unnecessary entanglements of DHCP with edge router functionality. Any dynamic IP address block address allocation will involve routing issues. Otherwise how does the traffic from Internet reaches those assigned subnets? You can do static routing, which means you pre-determine where the address block should go, which is the whole point we try to avoid. One can choose not to mention about the routing issue while talking about the subnet address allocation, but this does not make the operation issues go away. Even though Micro-blocking draft mentioning about the edge routing issues, but it does not tie it into the DHCP protocols, it is mentioned as the reasons we want to do this block address assignment in order to avoid routing scaling problems as mentioned in the draft, and the draft offers suggestions how the routing work with the extension to be scalable. ]4) Avoids the unnecessary new component of "proxy DHCP server" same as the above point. The reason you want to get a block of addresses is to manage them yourselves. this is the "proxy DHCP server" function, or in the draft-ietf-dhc-subnet-alloc-00.txt it was mentioned as "a Hierachical chain of DHCP servers", same idea. It does not matter one explicitly mentioned this "new component" or not, the basic idea of getting a block address is to further allocate them locally. The Micro-blocking draft does not have to require "proxy DHCP server", we can also say "client" needs this block of addresses if this helps:-) In the essence, Micro-blocking draft uses a simple suboption extension in dhcp protocol to make the DHCP server and clients to be a IP address-pool management system among multiple IP boxes, for the efficient address allocation. thanks. - Naiming ] ]John ] ]At 12:28 PM 1/24/2004, Naiming Shen wrote: ] ]>This draft has been posted, please review and comment. The authors ]>would like this draft to be adopted as a DHC working-group document. ]>... ]> ]>A new DHCP address allocation mechanism called Micro-blocking ]> is proposed in this document. It is used for DHCP proxy servers or ]> routers working with DHCP servers to maximize the IP address ]> allocation efficiency while improve dynamic routing scalability ]> in provider's networks. A DHCP sub-option within the relay agent ]> information option 82 is defined in this document. This simple ]> DHCP extension can be applied as a simple IP address-pool management ]> among multiple IP devices. ]> ]>A URL for this Internet-Draft is: ]>http://www.ietf.org/internet-drafts/draft-shen-dhc-block-alloc-01.txt ] _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 27 19:59:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07054; Tue, 27 Jan 2004 19:59: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 1Ale2n-0008U0-G7; Tue, 27 Jan 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 1Ale1s-0008Ss-NC for dhcwg@optimus.ietf.org; Tue, 27 Jan 2004 19:58: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 TAA07007 for ; Tue, 27 Jan 2004 19:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ale1q-0004ID-00 for dhcwg@ietf.org; Tue, 27 Jan 2004 19:58:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ale0s-0004Ek-00 for dhcwg@ietf.org; Tue, 27 Jan 2004 19:57:02 -0500 Received: from smtp106.mail.sc5.yahoo.com ([66.163.169.226]) by ietf-mx with smtp (Exim 4.12) id 1Aldzv-0004BG-00 for dhcwg@ietf.org; Tue, 27 Jan 2004 19:56:03 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@63.193.193.106 with login) by smtp106.mail.sc5.yahoo.com with SMTP; 28 Jan 2004 00:56:03 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IPR claims for Date: Tue, 27 Jan 2004 16:59:54 -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: <4.3.2.7.2.20040122113702.0290c2e0@flask.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=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 the timing is a bit unfortunate, but I agree with Ted that we should put this draft on hold until the group has had an opportunity to review and comment on the intellectual property rights claimed by PacketFront. After reading the notification referenced below, I find it impossible to tell what is actually being claimed by PacketFront, as there is no description either of intellectual property claimed by PacketFront or a description of how this Internet-Draft infringes on their rights. My inclination is to dismiss this out of hand as not being patentable as it is an obvious and trivial extension to prior work, which any well-informed practitioner could easily have suggested... but then, I've not spent years litigating patent claims. I don't intend to imply that Richard, Theyn, and Mark's work is trivial, but rather that it seems an obvious extension useful in several circumstances, hardly the stuff of a patent claim. Precisely because the proposed sub-option seems generally useful, I hesitate in suggesting we should place the draft on hold, as this then provides a de facto mechanism for vendors to halt IETF development of open standards by claiming unsubstantiated intellectual property rights for almost anything. Still, until the claimant specifically identifies what element(s) of this draft infringe on their IPR I think we should not advance this draft. --Barr > -----Original Message----- > From: Ralph Droms > Sent: Thursday, January 22, 2004 08:39 > > The WG should be aware of the following notice of IPR claims related to > 'DHCP Subscriber ID Suboption for the DHCP Relay Agent Option' > . The IPR claims are documented in > http://www.ietf.org/ietf/IPR/PacketFront-IPR.txt > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 27 21:09:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10506; Tue, 27 Jan 2004 21:09: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 1Alf8X-0003uV-5f; Tue, 27 Jan 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 1Alf7h-0003u7-3U for dhcwg@optimus.ietf.org; Tue, 27 Jan 2004 21:08: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 VAA10493 for ; Tue, 27 Jan 2004 21:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alf7e-00023Q-00 for dhcwg@ietf.org; Tue, 27 Jan 2004 21:08:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alf6h-00020n-00 for dhcwg@ietf.org; Tue, 27 Jan 2004 21:07:08 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Alf6X-0001yF-00 for dhcwg@ietf.org; Tue, 27 Jan 2004 21:06:58 -0500 Received: from [10.0.0.12] (cs241750-189.austin.rr.com [24.175.0.189]) by toccata.fugue.com (Postfix) with ESMTP id 6E9A41B9A8B; Tue, 27 Jan 2004 19:57:36 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <90E51C12-5136-11D8-9E6D-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] IPR claims for Date: Tue, 27 Jan 2004 20:06:20 -0600 To: X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 27, 2004, at 6:59 PM, Barr Hibbs wrote: > Precisely because the proposed sub-option seems generally useful, I > hesitate > in suggesting we should place the draft on hold, as this then provides > a de > facto mechanism for vendors to halt IETF development of open standards > by > claiming unsubstantiated intellectual property rights for almost > anything. > Still, until the claimant specifically identifies what element(s) of > this > draft infringe on their IPR I think we should not advance this draft. The particularly bizarre thing about this is that PacketFront sells devices that do DHCP, and presumably would like their devices to be standards-conformant. And yet they've done the worst thing they can do to assure that - they've asserted ownership over the standard, making it impractical for anyone but them to follow it. To me it seems like they are shooting themselves in the feet with large-caliber weapons. But what do I know? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 28 06:24:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25806; Wed, 28 Jan 2004 06:24: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 1Alnnd-0005m2-2y; Wed, 28 Jan 2004 06: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 1AlDVP-0007SA-VY for dhcwg@optimus.ietf.org; Mon, 26 Jan 2004 15:38: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 PAA19567 for ; Mon, 26 Jan 2004 15:38:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlDVO-0002v8-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 15:38:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlDUX-0002n0-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 15:37:57 -0500 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1AlDRf-0002X1-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 15:34:55 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0QKmV103967 for ; Mon, 26 Jan 2004 12:48:31 -0800 Date: Mon, 26 Jan 2004 12:48:31 -0800 (PST) From: Bernard Aboba 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=AWL autolearn=no version=2.60 Subject: [dhcwg] Proposed resolution to DNA issue 11: Reachability test Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.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 DNA issues list is available at: http://www.drizzle.com/~aboba/DNA/dnaissues.html The text of DNA issue 11 is enclosed below. The proposed resolution is as follows: Add the following definition to the terminology section (1.2): "Valid address In this specification, the term "valid address" refers to either a staticly configured IPv4 address, or an address assigned via DHCPv4 which has not been relinquished, and whose lease has not expired." Change Section 2.1 to the following: "2.1. Reachability Test The purpose of the reachability test is to determine whether the host is connected to a network on which it has a valid routable IPv4 address. The host skips the reachability test in the following circumstances: [a] If the host does not have good reason to believe that is connected to a network on which it has a valid routable IPv4 address. Since confirming failure of the reachability test requires considerable latency, mistakes are costly. In the absence of other evidence, a host SHOULD instead send a DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131], Section 3.2 and 4.3.2. [b] If the host believes that it is connected to a network on which it does not have a valid routable IPv4 address. A Link-Local IPv4 address does not count as a valid routable IPv4 address, nor does an IPv4 address assigned via DHCPv4, but whose lease has expired. In this case, the host SHOULD send a DHCPDISCOVER from the INIT state, as described in [RFC2131] Section 4.4. [c] If the host does not have information on default gateway(s) on the network to which it believes it is connected. The reachability test is performed by attempting to verify reachability of default gateway(s) on a former point of attachment. The host may probe only the primary default gateway, or it may probe primary and secondary default gateways, in series or in parallel. However, the host MUST only configure default gateway(s) which pass the reachability test. If the test is successful, the host may continue to use a valid routable IPv4 address without having to re-acquire it. This reduces roaming latency by allowing the host to bypass DHCP as well as subsequent Duplicate Address Detection (DAD). In contrast to a DHCP exchange, which may be between a DHCP client and an offlink DHCP server, the reachability test occurs between a host and its next hop router." --------------------------------------------------------------------------- Issue 11: Reachability test Submitter: Mark Stapp Submitter email address: mjs@cisco.com Date first submitted: November 11, 2003 Reference: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02702.html Document: DNAv4-04 Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue: I have some comments on draft-ietf-dhc-dna-ipv4-04.txt - on section 2.1 in particular. [2.1] Reachability Test Doesn't this sentence in 2.1 sort of turn DHCP on its head? "The purpose of the reachability test is to determine whether the host is connected to a network on which it had previously obtained a still valid routable IPv4 address." As I understand it, it's only the DHCP server who knows authoritatively whether the address binding that the client remembers is still valid. Working around that authority in circumstances where the server has failed, if the client could actually determine that, would be one thing. But working around that without the client's even attempting to confirm its binding with the server is problematic. This section states that a host may skip confirmation of its DHCP address when it reconnects under some circumstances. The DHCP INIT-REBOOT state is actually pretty important, and skipping it could have some undesireable consequences. As 2.1 is worded now, a host could have a week-old memory of an address it got on network A, and could re-use it upon reconnecting to network A without attempting INIT-REBOOT. That's a pretty dramatic change, if I've read the text accurately, and I'm not comfortable with it. Is the goal of 2.1 to assist clients who have marginal connections - wireless clients whose associations are flapping, for example? Maybe a time-based, stateful heuristic would be appropriate here. For example, if the host believes that it has reconnected to network A, and that it last communicated with the DHCP server on network A within the last - one minute? five minutes? - then it could proceed without INIT-REBOOT. If the host had a) been off of network A for more than five minutes, or b) been attached to some other network since it last attached to network A then it would go through INIT-REBOOT normally. Or are there folks who think that the client should always do INIT-REBOOT if it can? In that case, if there's a latency issue for some types of client or some types of link, maybe we should try to make a low-latency answer available from the server without changing the client behavior at all. [Ted Lemon] Some people have made a lot of what I would consider a misreading of RFC2131 - that INIT-REBOOT is optional. I believe it's optional because some hosts may not have stable store, not because hosts that *do* have stable store should ever skip INIT-REBOOT. I think that in order to get good behavior in the case where we have flapping going on on an 802.11 link, it's going to require a compromise on one of three directions. The choices are (remember, this is just for 802.11): - Try to do it right. This means that when we see a change, we look for a new configuration but don't immediately throw out the old, in the sense that we keep the old address configured alongside the new, and only kill it off after a timeout has passed. I don't think that anybody is going to implement this, and I'm not seriously proposing it - just wanted to mention it. - Compromise in the direction of switching quickly. This means that when we detect a possible change in attachment, we assume that the old connection is gone and never coming back. So we throw it away immediately and switch. MacOS X does this now. My wife Andrea was unable to get her email for quite a while this afternoon as a result, because she has a Titanium, which has, shall we say, antenna issues. She kept losing her access point in the middle of downloading her email, so she got the same ten messages quite a few times before she gave up. - Compromise in the direction of switching slowly. AFAIK nobody does this now. What this means is that when we notice a network transition, we keep it in mind, but don't try to reconfigure immediately - we wait 90 seconds, long enough for any active TCP sessions to time out. If, during that timeout period, the old network comes back, we continue using it. After this period has passed, we give up and move to the new network. This is a point solution for 802.11. I think that aggressive switching probably works fine for ethernet and similar media, because a change in media is usually a physical process. The solutions proposed in DNAv4 having to do with not trying to reconfigure until we actually detect a new link, as opposed to the loss of the old link, make a lot of sense - this means that if the switch is power cycled, we don't lose our address, but if we're plugged into a different switch, we get a new address quickly. [Mark Stapp] Couldn't quite tell from this whether you agreed with me that the text in the draft was ... too general. Like your wife, I've occasionally had 802.11 troubles, and I'd be interested in providing some guidelines that would make it easier for an 802.11 client to deal with those troubles better. I don't read INIT-REBOOT to mean 'throw out your configuration.' I've read it as 'try to confirm that your configuration is still valid'; there are lots of ways of optimizing the confirmation process. The dna draft proposes optimizing it by avoiding it - skipping the confirmation message based on some heuristic. The heuristic that's in the text isn't restricted to 802.11 clients, and isn't time-based or damped. The draft also doesn't discuss interactions between L2 (which notices that the link has gone down and been reconnected), the IP stack, and the DHCP client, and I agree with you that users are most likely to notice a transient link problem if it takes down their TCP connections. I'd like to distinguish 'reconfiguration' from 'confirmation'. I agree that helping 802.11 clients avoid unnecessary reconfiguration is desirable, and I'd support text that made specific recommendations for those clients. But the -04 draft loses the benefits of confirmation in too many situations. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 28 07:12:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25807; Wed, 28 Jan 2004 06:24: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 1Alnnc-0005lu-Kn; Wed, 28 Jan 2004 06: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 1AlDUf-0007RR-2X for dhcwg@optimus.ietf.org; Mon, 26 Jan 2004 15:38: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 PAA19439 for ; Mon, 26 Jan 2004 15:37:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlDUd-0002ns-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 15:37:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlDSe-0002aA-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 15:35:57 -0500 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1AlDPA-0002J7-00 for dhcwg@ietf.org; Mon, 26 Jan 2004 15:32:21 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0QKjZn03807 for ; Mon, 26 Jan 2004 12:45:35 -0800 Date: Mon, 26 Jan 2004 12:45:35 -0800 (PST) From: Bernard Aboba 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=AWL autolearn=no version=2.60 Subject: [dhcwg] Proposed resolution to DNA Issue 10: Strong vs. Weak hints Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.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 DNA issues list is available at: http://www.drizzle.com/~aboba/DNA/dnaissues.html The text of DNA issue 10 is enclosed below. The proposed resolution is as follows: Change Appendix A to the following: "Appendix A - Hints In order to assist in IPv4 network attachment detection, information associated with each network may be retained by the host. Based on IP and link-layer information, the host may be able to make an educated guess as to whether it has moved between subnets, or remained on the same subnet. If the host is likely to have moved between subnets, it may be possible to make an educated guess as to which subnet it has moved to. Since an educated guess is not the same as certainty, prior to concluding that the host remains on the same subnet, a reachability test MUST always be performed. IPv4 ICMP Router Discovery messages [RFC1256] provide information relating to prefix(es) available on the link. A host may use this information to conclude that an advertised prefix is available; however it cannot conclude the converse -- that prefixes not advertised are unavailable. For networks running over PPP [RFC1661], IP parameters negotiated in IPCP provide direct information on whether a previously obtained address remains valid on the link. On IEEE 802 [IEEE802] wired networks, hints include link-layer discovery traffic as well as information exchanged as part of IEEE 802.1X authentication [IEEE8021X]. Link-layer discovery traffic includes Link Layer Discovery Protocol (LLDP) [IEEE8021AB] traffic as well as network identification information passed in the EAP-Request/Identity or within an EAP method exchange, as defined in EAP [RFC2284bis]. For example, LLDP advertisements can provide information on VLANs supported by the device. When used with IEEE 802.1X authentication [IEEE8021X], the EAP-Request/Identity exchange may contain the name of the authenticator, also providing information on the potential network. Similarly, during the EAP method exchange the authenticator may supply information that may be helpful in identifying the network to which the device is attached. However, as noted in [RFC3580], it is possible for the VLANID defined in [IEEE8021Q] to be assigned dynamically, so this static information may not prove definitive. In IEEE 802.11 [IEEE80211] stations provide information in Beacon and/or Probe Response messages, such as the SSID, BSSID, and capabilities, as well as information on whether the station is operating in Infrastructure or Adhoc mode. As described in [RFC3580], it is possible to assign a Station to a VLAN dynamically, based on the results of IEEE 802.1X [IEEE8021X] authentication. This implies that a single SSID may offer access to multiple VLANs, and in practice most large WLAN deployments offer access to multiple subnets. Thus, associating to the same SSID is a necessary, but not necessarily a sufficient condition, for remaining within the same subnet: while a Station associating to the same SSID may not necessarily remain within the same subnet, a Station associating to a different SSID is likely to have changed subnets. Since the SSID is a non-unique identifier, and SSIDs such as "default", "linksys" and "tsunami" are advertised by default in various products, detection of these "default SSIDs" is not sufficient for a host to conclude that it has remained on the same subnet. It is recommended that before detecting a match to a "default SSID" that the BSSID also be checked before concluding that the host remains on the same subnet. In order to provide additional guidance on the subnets to which a given AP offers access, additional subnet-related Information Elements (IEs) have been proposed for addition to the IEEE 802.11 Beacon and Probe Response messages. As noted earlier, VLANs may be determined dynamically so that these information elements may not be reliable." ----------------------------------------------------------------- Issue 10: Strong vs. Weak hints Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 10, 2003 Reference: Document: DNAv4-04 Comment type: T Priority: S Section: Appendix A Rationale/Explanation of issue: The distinction between "strong" and "weak" hints is not entirely clear to me. I think that the distinction does not affect protocol operation -- it's just affects the likelihood of success. For example, if there is any chance that a hint is not definitive, then the host needs to do a check anyway (such as a reachability test or a DHCPREQUEST). So behavior doesn't really change based on hint strength. The specification should say this. It's unclear now. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 28 23:13:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17130; Wed, 28 Jan 2004 23: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 1Am3Y3-0007XZ-Ls; Wed, 28 Jan 2004 23: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 1Am3X6-0007Uo-UC for dhcwg@optimus.ietf.org; Wed, 28 Jan 2004 23:12: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 XAA17113 for ; Wed, 28 Jan 2004 23:11:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am3X2-0000bO-00 for dhcwg@ietf.org; Wed, 28 Jan 2004 23:11:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am3W7-0000WT-00 for dhcwg@ietf.org; Wed, 28 Jan 2004 23:11:00 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1Am3VN-0000Me-00 for dhcwg@ietf.org; Wed, 28 Jan 2004 23:10: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 <0HS800I04GW694@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 29 Jan 2004 13:09:43 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HS800DOKGW6DB@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 29 Jan 2004 13:09:42 +0900 (KST) Received: from LocalHost ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HS800MSHGW5TV@mmp2.samsung.com> for dhcwg@ietf.org; Thu, 29 Jan 2004 13:09:42 +0900 (KST) Date: Thu, 29 Jan 2004 13:09:33 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Accept as WG work item? In-reply-to: To: dhcwg@ietf.org Cc: Ralph Droms , soohong.park@samsung.com Message-id: <003601c3e61d$b3865070$b7cbdba8@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.3 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 would like to verify below drafts were accepted as work items. If yes, it's time to publish them before cut-off date IMHO. Ralph. please let us know your decision on this. Best wishes. Daniel (Soohong Daniel Park) > I think these drafts are worth consideration... > > draft-senthil-dhc-proxyserver-opt > > draft-vijay-dhc-opt-extrboot > > draft-vijay-dhc-dhcpv6-ipv6trans > > draft-vijay-dhc-dhcpv6-opt-rboot > > > > --kan-- > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 10:21:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23682; Thu, 29 Jan 2004 10:21: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 1AmDyY-0005du-0F; Thu, 29 Jan 2004 10:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDxh-0005Wy-As for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 10:20:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23394; Thu, 29 Jan 2004 10:20:05 -0500 (EST) Message-Id: <200401291520.KAA23394@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, 29 Jan 2004 10:20:05 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-05.txt Pages : 14 Date : 2004-1-28 The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This specification synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-Local addresses, in order to optimize detection of network attachment by mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dna-ipv4-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-29104156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-29104156.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 Jan 29 12:26:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02783; Thu, 29 Jan 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 1AmFuY-0006AI-Ca; Thu, 29 Jan 2004 12: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 1AmFmS-0004zW-Ll for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 12:16: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 MAA02216 for ; Thu, 29 Jan 2004 12:16:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmFmR-0002rl-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 12:16:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmFlY-0002kR-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 12:15:45 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AmFl1-0002dg-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 12:15:11 -0500 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 i0THEcEs029207 for ; Thu, 29 Jan 2004 09:14:38 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-113.cisco.com [10.86.242.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFQ49844; Thu, 29 Jan 2004 12:14:32 -0500 (EST) Message-Id: <4.3.2.7.2.20040129120940.02b6d1f8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 12:14:26 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] New drafts as WG work items? In-Reply-To: <4.3.2.7.2.20031229075610.01ead5f8@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: , Based on review and feedback on the WG mailing list, the WG will take on the following drafts as WG work items: (which updates ) - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 12:36:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03605; Thu, 29 Jan 2004 12:36: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 1AmG5A-0008Q0-JQ; Thu, 29 Jan 2004 12:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmG4f-0008Nh-U4 for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 12:35: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 MAA03552 for ; Thu, 29 Jan 2004 12:35:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmG4e-0005bn-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 12:35:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmG3g-0005VQ-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 12:34:28 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AmG2o-0005KM-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 12:33:34 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 29 Jan 2004 09:33:12 -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 i0THWwAe007402 for ; Thu, 29 Jan 2004 12:33:00 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-113.cisco.com [10.86.242.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFQ51199; Thu, 29 Jan 2004 12:29:46 -0500 (EST) Message-Id: <4.3.2.7.2.20040129122321.02b3cdb8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 12:29:44 -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] New draft as WG work item Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We have a request to consider the following draft as a WG work item: Requirements for Proposed Changes to the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Abstract This memo describes the requirements of Internet-Drafts proposing changes to the Dynamic Host Configuration Protocol for IPv4 (DHCPv4). These requirements specifically cover documentation expected whenever message formats or client state transitions are modified. It is my judgment that this draft provides a useful set of requirements to be used in evaluating future updates and extensions to DHCP. Please post comments about this draft to the dhcwg@ietf.org mailing list before 5PM Friday, 1/30. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 14:33:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10873; Thu, 29 Jan 2004 14: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 1AmHuO-0007C1-Dn; Thu, 29 Jan 2004 14:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHtz-00078L-JO for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 14:32: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 OAA10786 for ; Thu, 29 Jan 2004 14:32:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHtw-000544-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 14:32:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHt5-0004wG-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 14:31:39 -0500 Received: from smtp101.mail.sc5.yahoo.com ([216.136.174.139]) by ietf-mx with smtp (Exim 4.12) id 1AmHsD-0004pZ-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 14:30:45 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.145 with login) by smtp101.mail.sc5.yahoo.com with SMTP; 29 Jan 2004 19:30:44 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] New draft as WG work item Date: Thu, 29 Jan 2004 11:34:40 -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: <4.3.2.7.2.20040129122321.02b3cdb8@flask.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=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 As the author, I obviously favor this short draft, and would like to give an expanded rationale for it. From our review of RFC2131 one of the common threads has been that certain sections of the RFC were not kept in synch with the rest of the changes occurring in separate I-Ds or RFCs. I've presented what I think is a reasonable set of requirements that SHOULD be met by any future I-D author to address these synchronization problems. Specific items include: (1) updating the client state machine diagram whenever a new message type is added or the behavior of an existing message type is changed (or, as was recently suggested on the mailing list, when a new state is added) (2) updating the tables giving requirements for certain protocol fields in the message formats whenever the relationship between fields is changed, a new protocol field is added, or (however unlikely) a protocol field is deleted (3) updating the text of the RFC whenever an I-D proposes a change in the behavior of the protocol, identifies a conflict, or attempts to resolve interactions between other features of the protocol As I believe that each of these is something that an author should be doing as part of the implied "due diligence" to create workable RFCs, I don't believe that any of them represent an undue burden on I-D authors. This work could be extended to include DHCPv6 if the Working Group desires. Thanks, --Barr > We have a request to consider the following draft as a WG work item: > > Requirements for Proposed Changes to the > Dynamic Host Configuration Protocol for IPv4 (DHCPv4) > > > > > Abstract > > This memo describes the requirements of Internet-Drafts proposing > changes to the Dynamic Host Configuration Protocol for IPv4 > (DHCPv4). > These requirements specifically cover documentation > expected whenever > message formats or client state transitions are modified. > > It is my judgment that this draft provides a useful set of requirements to > be used in evaluating future updates and extensions to DHCP. Please post > comments about this draft to the dhcwg@ietf.org mailing list before 5PM > Friday, 1/30. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 16:24:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19199; Thu, 29 Jan 2004 16:24:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJeF-0007xv-7Z; Thu, 29 Jan 2004 16:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJN9-0006Qk-K2 for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 16:06: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 QAA18497 for ; Thu, 29 Jan 2004 16:06:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmJN7-0002Ak-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:06:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmJM5-000235-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:05:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AmJLb-0001wJ-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:05:11 -0500 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 i0TL4YAg006493 for ; Thu, 29 Jan 2004 16:04:39 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-113.cisco.com [10.86.242.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFQ73821; Thu, 29 Jan 2004 16:00:03 -0500 (EST) Message-Id: <4.3.2.7.2.20040129154925.02b51c88@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 15:57: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] Extending the set of available DHCP option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At the WG meeting in Minneapolis, the WG accepted two mechanisms for extending the set of available DHCP option codes from draft-ietf-dhc-extended-optioncodes-00.txt: (1) redesignate option codes 128-223 to be assigned to new options (2) recover disused option codes (the "Impress Server" option being the canonical example) for reassignment to new options It turns out we misunderstood the second of these two mechanisms; the author of draft-ietf-dhc-extended-optioncodes-00.txt (Bernie Volz) was referring to option codes already under consideration for reclamation in "Unused Dynamic Host Configuration Protocol (DHCP) Option Codes" (RFC 3679), rather than option codes defined in RFC 2132 that currently see little use. Therefore, we should not follow up on (2) and will pursue only (1) (which is now published as draft-ietf-dhc-reclassify-options-00). - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 16:24:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19198; Thu, 29 Jan 2004 16:24:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJe9-0007sz-LG; Thu, 29 Jan 2004 16:24:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJ0m-00056l-1Z for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 15:43: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 PAA17481 for ; Thu, 29 Jan 2004 15:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmJ0k-0007O2-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 15:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmIzv-0007Hv-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 15:42:47 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx with esmtp (Exim 4.12) id 1AmIza-00079y-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 15:42:26 -0500 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 29 Jan 2004 12:49:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by syd-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0TNf8Za002549 for ; Fri, 30 Jan 2004 07:41:10 +0800 (WST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-113.cisco.com [10.86.242.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFQ71613; Thu, 29 Jan 2004 15:41:39 -0500 (EST) Message-Id: <4.3.2.7.2.20040129152633.08583db0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 15:41:35 -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-3315id-for-v4-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: , As discussed at the IETF meeting in Minneapolis, draft-ietf-dhc-3315id-for-v4-01.txt has been published. An HTML diff between the -00 revision and the -01 revision is available at http://www.dhcp.org/meetings.html. Please review the new revision and post comments to the mailing list prior to discussion at the WG meeting in Seoul, where we will determine if the document is ready for WG last call. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 16:25:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19302; Thu, 29 Jan 2004 16:25:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJeN-00086v-5W; Thu, 29 Jan 2004 16:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJYh-0007Ev-4k for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 16:18: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 QAA18977 for ; Thu, 29 Jan 2004 16:18:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmJYf-0003Yo-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:18:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmJXl-0003S3-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:17: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 1AmJXK-0003Jl-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:17:18 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 29 Jan 2004 13:22:32 +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 i0TLGkPn016588 for ; Thu, 29 Jan 2004 13:16:47 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-113.cisco.com [10.86.242.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFQ76115; Thu, 29 Jan 2004 16:15:19 -0500 (EST) Message-Id: <4.3.2.7.2.20040129160545.01f01008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 16:15:17 -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] Discussion of DHCP implementation 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: , At the WG meeting in Minneapolis, the WG reviewed draft-ietf-dhc-implementation-01.txt. During the review, the WG decided to hold a conference call and possibly a workshop to come to closure on the various issues in draft-ietf-dhc-implementation-01.txt. I'd like to schedule the conf call for the week of 2/23 (the week before the IETF meeting in Seoul). To begin organizing the call, please respond to the dhcwg list with: * an indication if you are interested in joining the call * your timezone and available times * goals for the meeting * specific agenda items - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 16:54:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21778; Thu, 29 Jan 2004 16:54: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 1AmK6r-0003US-A5; Thu, 29 Jan 2004 16: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 1AmK6a-0003T0-K4 for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 16:53: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 QAA21733 for ; Thu, 29 Jan 2004 16:53:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmK6Y-0001CZ-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:53:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmK5m-00016D-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:52:54 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AmK5M-0000xw-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:52:28 -0500 Received: from [10.0.0.12] (cs241750-189.austin.rr.com [24.175.0.189]) by toccata.fugue.com (Postfix) with ESMTP id 0B3CE1EFFB1; Thu, 29 Jan 2004 15:43:20 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040129155743.02b51c88@flask.cisco.com> References: <4.3.2.7.2.20040129155743.02b51c88@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B1F28D9-52A5-11D8-ADDC-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] RE: draft-ietf-dhc-3315id-for-v4-01.txt Date: Thu, 29 Jan 2004 15:52:22 -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 Jan 29, 2004, at 3:02 PM, Ralph Droms wrote: > Looks to me like we're waiting for a new > revision to continue the discussion. That's right. Also, I published an individual submission that I'd like the WG to consider before Seoul. This is about a related issue. I haven't brought it up yet because I wanted to bring it up in connection with a discussion about the -02 version of the 3315id draft, which I haven't yet had time to prepare. :'/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 17:07:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22692; Thu, 29 Jan 2004 17:07: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 1AmKJT-0004tc-NL; Thu, 29 Jan 2004 17:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEXr-00016D-Bz for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 10: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 KAA28163 for ; Thu, 29 Jan 2004 10:57:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmEXo-0000x5-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 10:57:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmEX9-0000pd-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 10:56:47 -0500 Received: from mailhost.packetfront.com ([192.121.165.2]) by ietf-mx with esmtp (Exim 4.12) id 1AmEWI-0000dQ-00; Thu, 29 Jan 2004 10:55:55 -0500 Received: from [192.168.1.145] (helo=pfmatjon) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 1AmER6-0005wr-00; Thu, 29 Jan 2004 16:50:32 +0100 From: "Mats Jonsson" To: Cc: , Date: Thu, 29 Jan 2004 16:52:33 +0100 Message-ID: <008701c3e67f$e8f82f00$9101a8c0@int.packetfront.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C3E688.4ABC9700" 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=HTML_70_80,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] Regarding 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: , This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C3E688.4ABC9700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PacketFront Sweden AB would like to update its IPR notification from = April 17, 2003. =20 The document draft-ietf-dhc-subscriber-id-X.txt describes technology or solutions for which PacketFront has related patents or patent = applications pending.=20 =20 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. =20 PacketFront Sweden AB Mats E. Jonsson Deputy CEO =20 =20 ------=_NextPart_000_0088_01C3E688.4ABC9700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 

PacketFront Sweden = AB

Mats = E. Jonsson

Deputy = CEO

 

 

------=_NextPart_000_0088_01C3E688.4ABC9700-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 17:12:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19200; Thu, 29 Jan 2004 16:24:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJeH-00080Q-KS; Thu, 29 Jan 2004 16:24:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJO7-0006hc-Lq for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 16:07: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 QAA18597 for ; Thu, 29 Jan 2004 16:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmJO5-0002J7-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:07:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmJNB-0002BK-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:06:50 -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 1AmJMa-00023C-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 16:06:12 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Jan 2004 13:10:46 +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 i0TL5NQ3015790 for ; Thu, 29 Jan 2004 13:05:40 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-113.cisco.com [10.86.242.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFQ74111; Thu, 29 Jan 2004 16:02:10 -0500 (EST) Message-Id: <4.3.2.7.2.20040129155743.02b51c88@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 16:02: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] RE: draft-ietf-dhc-3315id-for-v4-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: , Sorry - I'm behind on the discussion on the WG mailing list, where this draft has already been discussed. Looks to me like we're waiting for a new revision to continue the discussion. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 17:45:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25242; Thu, 29 Jan 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 1AmKuE-0008Sf-TT; Thu, 29 Jan 2004 17:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKu4-0008Rx-Bc for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 17:44: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 RAA25183 for ; Thu, 29 Jan 2004 17:44:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmKu1-00019F-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 17:44:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmKt9-0000zm-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 17:43:56 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AmKsE-0000qT-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 17:42:59 -0500 Received: from [10.0.0.12] (cs241750-189.austin.rr.com [24.175.0.189]) by toccata.fugue.com (Postfix) with ESMTP id 7CA461EFFF8; Thu, 29 Jan 2004 16:33:53 -0600 (CST) In-Reply-To: <008701c3e67f$e8f82f00$9101a8c0@int.packetfront.com> References: <008701c3e67f$e8f82f00$9101a8c0@int.packetfront.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B4CFEB4-52AC-11D8-ADDC-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: "" , "" From: Ted Lemon Subject: Re: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 29 Jan 2004 16:42:56 -0600 To: "Mats Jonsson" 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=1.0 required=5.0 tests=AWL,NO_STRINGS 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 Jan 29, 2004, at 9:52 AM, Mats Jonsson wrote: > 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. That's somewhat encouraging, but can you say what terms you would offer? I'm personally not at all happy with the idea that any part of the DHCP protocol suite might be subject to a license fee. The only standard in the DHCwg that contains any patented IP (that I know of) is the relay agent information option draft, and to the best of my recollection Motorola stated that they would not demand any compensation from software or hardware manufacturers who implement RFC3046, other than in cases where there might be cross-licensing issues. I think that PacketFront owes the DHCwg an explanation for why they have added these trivial patents on top of a protocol that is otherwise unencumbered - how you justify this kind of action toward a group that has produced something of great value to you and offered it to you with no strings attached. If these are purely defensive patents, that's a good explanation, but if that's the case, your licensing terms should be stated in way that's compatible with that interpretation. Unfortunately, "reasonable" is far too vague to satisfy this. I personally am against advancing this draft until we have some assurance that there will be no license fees for this patent except in cases where there is a need for cross-licensing. I have no objection to you protecting your interests, but I do object to the DHCwg advancing a draft which encumbers the DHCP protocol suite in this way, and I don't think this draft adds sufficient value to justify advancing the draft under the present circumstances. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 17:54:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25974; Thu, 29 Jan 2004 17:54: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 1AmL2v-0000nN-4x; Thu, 29 Jan 2004 17: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 1AmL2a-0000mt-TU for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 17:53: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 RAA25787 for ; Thu, 29 Jan 2004 17:53:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmL2Y-0002a3-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 17:53:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmL1M-0002Ht-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 17:52:25 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1AmL0L-00020H-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 17:51:21 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.36 #1 (Debian)) id 1AmKzH-0007Ld-00; Thu, 29 Jan 2004 14:50:15 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jan 2004 14:50:10 -0800 Message-ID: From: "Kostur, Andre" To: "'Ted Lemon'" , Mats Jonsson Cc: "" , "" Subject: RE: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 29 Jan 2004 14:50:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E6BA.3F025990" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_STRINGS 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_01C3E6BA.3F025990 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Thursday, January 29, 2004 2:43 PM > To: Mats Jonsson > Cc: ; > Subject: Re: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt > > On Jan 29, 2004, at 9:52 AM, Mats Jonsson wrote: > > 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. > > That's somewhat encouraging, but can you say what terms you would > offer? I'm personally not at all happy with the idea that > any part of > the DHCP protocol suite might be subject to a license fee. > > The only standard in the DHCwg that contains any patented IP (that I > know of) is the relay agent information option draft, and to the best > of my recollection Motorola stated that they would not demand any > compensation from software or hardware manufacturers who implement > RFC3046, other than in cases where there might be cross-licensing > issues. > > I think that PacketFront owes the DHCwg an explanation for why they > have added these trivial patents on top of a protocol that is > otherwise > unencumbered - how you justify this kind of action toward a > group that > has produced something of great value to you and offered it > to you with > no strings attached. If these are purely defensive patents, > that's a > good explanation, but if that's the case, your licensing terms should > be stated in way that's compatible with that interpretation. > > Unfortunately, "reasonable" is far too vague to satisfy this. I > personally am against advancing this draft until we have some > assurance > that there will be no license fees for this patent except in cases > where there is a need for cross-licensing. I have no > objection to you > protecting your interests, but I do object to the DHCwg advancing a > draft which encumbers the DHCP protocol suite in this way, > and I don't > think this draft adds sufficient value to justify advancing the draft > under the present circumstances. I agree with Ted. I think that the licencing terms should be spelled out specifically, as well as exactly which patents cover the work within the draft. ------_=_NextPart_001_01C3E6BA.3F025990 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@nominum.com]
> Sent: Thursday, January 29, 2004 2:43 PM
> To: Mats Jonsson
> Cc: <dhcwg@ietf.org>; <frenym@packetfront.com>
> Subject: Re: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt
>
> On Jan 29, 2004, at 9:52 AM, Mats Jonsson wrote:
> > 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.
>
> That's somewhat encouraging, but can you say what terms you would
> offer?   I'm personally not at all happy with the idea that
> any part of
> the DHCP protocol suite might be subject to a license fee.
>
> The only standard in the DHCwg that contains any patented IP (that I
> know of) is the relay agent information option draft, and to the best
> of my recollection Motorola stated that they would not demand any
> compensation from software or hardware manufacturers who implement
> RFC3046, other than in cases where there might be cross-licensing
> issues.
>
> I think that PacketFront owes the DHCwg an explanation for why they
> have added these trivial patents on top of a protocol that is
> otherwise
> unencumbered - how you justify this kind of action toward a
> group that
> has produced something of great value to you and offered it
> to you with
> no strings attached.   If these are purely defensive patents,
> that's a
> good explanation, but if that's the case, your licensing terms should
> be stated in way that's compatible with that interpretation.
>
> Unfortunately, "reasonable" is far too vague to satisfy this.   I
> personally am against advancing this draft until we have some
> assurance
> that there will be no license fees for this patent except in cases
> where there is a need for cross-licensing.   I have no
> objection to you
> protecting your interests, but I do object to the DHCwg advancing a
> draft which encumbers the DHCP protocol suite in this way,
> and I don't
> think this draft adds sufficient value to justify advancing the draft
> under the present circumstances.

I agree with Ted.  I think that the licencing terms should be spelled out specifically, as well as exactly which patents cover the work within the draft.

------_=_NextPart_001_01C3E6BA.3F025990-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 18:12:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27726; Thu, 29 Jan 2004 18:12: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 1AmLKL-0006tF-Uw; Thu, 29 Jan 2004 18:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLKF-0006rG-Sv for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 18:11: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 SAA27642 for ; Thu, 29 Jan 2004 18:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmLKC-0005DW-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 18:11:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmLJR-00054j-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 18:11:06 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AmLId-0004t3-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 18:10:16 -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 i0TNA3Gn086657; Thu, 29 Jan 2004 18:10:12 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" , "'Mats Jonsson'" Cc: , , "'Kostur, Andre'" Subject: RE: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt Date: Thu, 29 Jan 2004 18:10:02 -0500 Message-ID: <000201c3e6bd$0a171c40$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C3E693.21411440" 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.1 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_MESSAGE autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C3E693.21411440 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I also agree with Ted (and Andre) - we should not advance the draft. - Bernie ------=_NextPart_000_0003_01C3E693.21411440 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt

I also agree with Ted (and Andre) = – we should not advance the draft.

 

- Bernie

 

------=_NextPart_000_0003_01C3E693.21411440-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 22:53:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09846; Thu, 29 Jan 2004 22:53: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 1AmPiH-00044I-Vs; Thu, 29 Jan 2004 22: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 1AmPiA-00043x-Ae for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 22:52: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 WAA09836 for ; Thu, 29 Jan 2004 22:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmPi6-0002FC-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 22:52:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmPhB-00027x-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 22:51:54 -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 1AmPgQ-0001uv-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 22:51:06 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 29 Jan 2004 19:56:23 +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 i0U3oOL9025658 for ; Thu, 29 Jan 2004 19:50:35 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-113.cisco.com [10.86.242.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFQ95470; Thu, 29 Jan 2004 19:41:51 -0500 (EST) Message-Id: <4.3.2.7.2.20040129193209.02b91dc0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 19:41:48 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Agenda items for IETF-59, 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 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 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 the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) 05 minutes Node-Specific Client Identifiers for DHCPv4 05 minutes Rapid Commit Option for DHCPv4 05 minutes Update on IPR issue with two drafts Ralph Droms 15 minutes Update of dhc WG charter Ralph Droms 15 minutes ----------- Total 70 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 29 23:36:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11021; Thu, 29 Jan 2004 23:36: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 1AmQNt-0006KT-RX; Thu, 29 Jan 2004 23: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 1AmQNh-0006K4-CK for dhcwg@optimus.ietf.org; Thu, 29 Jan 2004 23:35: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 XAA10999 for ; Thu, 29 Jan 2004 23:35:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmQNf-000702-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 23:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmQMg-0006sM-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 23:34:46 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1AmQLh-0006hE-00 for dhcwg@ietf.org; Thu, 29 Jan 2004 23:33:46 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6ED6695B8EE; Thu, 29 Jan 2004 20:33:44 -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 06300-02; Thu, 29 Jan 2004 20:33:44 -0800 (PST) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 064A395B8ED; Thu, 29 Jan 2004 20:33:44 -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 UAA15597; Thu, 29 Jan 2004 20:33:43 -0800 (PST) Message-Id: <200401300433.UAA15597@redback.com> To: Ralph Droms Cc: dhcwg@ietf.org, kishore@redback.com, souissal@redback.com, tom_soon@labs.sbc.com, phantom@kt.co.kr Subject: Re: [dhcwg] Agenda items for IETF-59, Seoul In-reply-to: Mail from Ralph Droms dated Thu, 29 Jan 2004 19:41:48 EST <4.3.2.7.2.20040129193209.02b91dc0@flask.cisco.com> Date: Thu, 29 Jan 2004 20:33:43 -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: , 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 From dhcwg-admin@ietf.org Fri Jan 30 05:10:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05736; Fri, 30 Jan 2004 05: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 1AmVbC-0003Ub-DV; Fri, 30 Jan 2004 05:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmVaN-0003Hr-UT for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 05:09: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 FAA05677 for ; Fri, 30 Jan 2004 05:09:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmVaK-0007Wd-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 05:09:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmVZV-0007Oa-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 05:08:21 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmVYw-0007FW-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 05:07:46 -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 i0UA7kOr012121 for ; Fri, 30 Jan 2004 10:07:46 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 KAA14340 for ; Fri, 30 Jan 2004 10:07:45 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i0UA7j608202 for dhcwg@ietf.org; Fri, 30 Jan 2004 10:07:45 GMT Date: Fri, 30 Jan 2004 10:07:45 +0000 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Agenda items for IETF-59, Seoul Message-ID: <20040130100745.GB7484@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <4.3.2.7.2.20040129193209.02b91dc0@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.20040129193209.02b91dc0@flask.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-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 Ralph, Could we add draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt ? There are also one or two proposed solution drafts, but there may be a wider issue (as I recall you posted a month ago) to be discussed. I can't be in Seoul, but Stig Venaas, co-author, has said he could present. I will also shortly submit the DHCPv4/v6 issues draft, which again Stig should be able to present, if you think it's worth 10(?) mins on the agenda. Tim On Thu, Jan 29, 2004 at 07:41:48PM -0500, Ralph Droms wrote: > 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 > 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 the Dynamic Host Configuration > Protocol for IPv4 (DHCPv4) 05 minutes > > > Node-Specific Client Identifiers for DHCPv4 05 > minutes > > > Rapid Commit Option for DHCPv4 05 > minutes > > > Update on IPR issue with two drafts Ralph Droms 15 > minutes > > Update of dhc WG charter Ralph Droms 15 > minutes > ----------- > Total 70 > minutes > > > _______________________________________________ > 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 Jan 30 05:22:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06245; Fri, 30 Jan 2004 05:22: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 1AmVml-0004Mg-F6; Fri, 30 Jan 2004 05:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmVlw-0004Lj-6N for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 05: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 FAA06218 for ; Fri, 30 Jan 2004 05:21:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmVls-0001GO-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 05:21:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmVky-00019G-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 05:20:12 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AmVkU-00011e-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 05:19:42 -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 i0UAJA8m031093 for ; Fri, 30 Jan 2004 11:19:10 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i0UAJAQU030239 for dhcwg@ietf.org; Fri, 30 Jan 2004 11:19:10 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 30 Jan 2004 11:19:10 +0100 From: Stig Venaas To: dhcwg@ietf.org Subject: Re: [dhcwg] Agenda items for IETF-59, Seoul Message-ID: <20040130101859.GH29872@sverresborg.uninett.no> References: <4.3.2.7.2.20040129193209.02b91dc0@flask.cisco.com> <20040130100745.GB7484@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040130100745.GB7484@login.ecs.soton.ac.uk> 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, Jan 30, 2004 at 10:07:45AM +0000, Tim Chown wrote: > Hi Ralph, > > Could we add draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt ? > > There are also one or two proposed solution drafts, but there may be a > wider issue (as I recall you posted a month ago) to be discussed. I can't > be in Seoul, but Stig Venaas, co-author, has said he could present. I would like to present that one, say 10 minutes, and also if possible draft-venaas-dhc-lifetime-01.txt which is one possible solution. That should be about 3 minutes. Or is it too early to present solutions? Might need some additional time for discussion though. > I will also shortly submit the DHCPv4/v6 issues draft, which again Stig > should be able to present, if you think it's worth 10(?) mins on the agenda. Yes, I could do that I guess. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 08:09:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13531; Fri, 30 Jan 2004 08: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 1AmYOL-0006UV-H2; Fri, 30 Jan 2004 08: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 1AmYNa-0006To-Dp for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 08:08: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 IAA13504 for ; Fri, 30 Jan 2004 08:08:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmYNZ-0007EF-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 08:08:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmYMf-00076S-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 08:07:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AmYMC-0006z0-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 08:06:48 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2004 05:06:20 -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 i0UD6Cgx000455 for ; Fri, 30 Jan 2004 08:06:16 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-92.cisco.com [10.86.240.92]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFR18158; Fri, 30 Jan 2004 07:43:56 -0500 (EST) Message-Id: <4.3.2.7.2.20040130073948.01fb30a0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Jan 2004 07:43: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] Important dates for IETF-59, 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: , IMPORTANT!! dhc WG Internet Drafts with rev num -00 *MUST* be received by internet-drafts@ietf.org by 0900 EST, Monday, 2/9/2004. Other Internet Drafts *MUST* be received by internet-drafts@ietf.org by 0900 EST, Monday, 2/16/2004. There are no extensions on these deadlines... Other important dates for IETF-59: February 9, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 12, Thursday - Working Group and BOF scheduling closes at 17:00 ET February 16, Monday - Internet Draft final submission cut-off at 09:00 ET February 16, Monday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET February 23, Monday - Registration cancellation cut-off at 17:00 ET February 24, Tuesday - Working Group agendas due date at 12:00 ET February 29-March 5 - 59th IETF Meeting in Seoul, Korea _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 08:17:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14744; Fri, 30 Jan 2004 08:17: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 1AmYW4-00076g-F5; Fri, 30 Jan 2004 08: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 1AmYVz-00075k-56 for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 08:16: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 IAA14595 for ; Fri, 30 Jan 2004 08:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmYVy-00011D-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 08:16:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmYUx-0000nH-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 08:15:52 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AmYTW-0000Kp-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 08:14:22 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0UDDk5B512996; Fri, 30 Jan 2004 08:13:46 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-253-171.mts.ibm.com [9.65.253.171]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0UDDfBs166852; Fri, 30 Jan 2004 06:13:42 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0UDD8A08896; Fri, 30 Jan 2004 08:13:13 -0500 Message-Id: <200401301313.i0UDD8A08896@cichlid.raleigh.ibm.com> To: Ted Lemon cc: "Mats Jonsson" , "" , "" Subject: Re: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt In-Reply-To: Message from mellon@nominum.com of "Thu, 29 Jan 2004 16:42:56 CST." <7B4CFEB4-52AC-11D8-ADDC-000A95D9C74C@nominum.com> Date: Fri, 30 Jan 2004 08:13: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.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 only standard in the DHCwg that contains any patented IP (that I > know of) is the relay agent information option draft, and to the best > of my recollection Motorola stated that they would not demand any > compensation from software or hardware manufacturers who implement > RFC3046, other than in cases where there might be cross-licensing > issues. To be clear, Motorola's statement is here: http://www.ietf.org/ietf/IPR/MOTOROLA-DHCP-AGENT-OPTIONS Also, to be fair, there have been other assertions of IPR on DHC work items, though they are not RFCs yet. See Section 10 of draft-ietf-dhc-agentopt-radius-03.txt, for which a WG Last Call has completed. And see also Section 10 of draft-ietf-dhc-subnet-alloc-00.txt (though expired), which I presume relates to http://www.ietf.org/ietf/IPR/CISCO-raj-dhc-subnet-alloc.txt. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 10:21:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21382; Fri, 30 Jan 2004 10:21: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 1AmaS5-0004Pq-Og; Fri, 30 Jan 2004 10: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 1AmaRJ-0004M4-1U for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 10:20: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 KAA21334 for ; Fri, 30 Jan 2004 10:20:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmaRG-0001WC-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 10:20:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmaQJ-0001P2-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 10:19:12 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AmaPS-0001HI-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 10:18:18 -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 i0UFI3Gn092824; Fri, 30 Jan 2004 10:18:12 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" Cc: Subject: RE: [dhcwg] RE: draft-ietf-dhc-3315id-for-v4-01.txt Date: Fri, 30 Jan 2004 10:18:05 -0500 Message-ID: <000001c3e744$45c8dd50$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: <6B1F28D9-52A5-11D8-ADDC-000A95D9C74C@fugue.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 Ted: I assume you refer to draft-lemon-dhcpv4-to-v6-id-trans-00.txt. I = reviewed it quickly and is this pain really worth it just to change your = identifier? I doubt it. Many identifiers are derived from NIC addresses and few = think twice about changing that hardware ... you just go with a new address. Also, the switch to using the DUID would likely occur after a software upgrade which typically also requires a reboot. So, there would usually = be no sessions active and thus no major issue if the address changes. And, just like with other upgrades, if a site started rolling out large numbers of new clients, they could adjust the lease times on the servers = to use shorter leases for the rollout to allow faster reuse of addresses. For the cases where a system needs to keep its current address, likely = there is a reservation for that lease. So, if the client's software upgrade procedure reports the current client identifier and the new DUID it will = use (before using it), the server's configuration can be updated. Ideally, servers might want to allow multiple client identifiers for a = reservation to support changes in client identifiers? The above also avoids security issues, especially with client options to change ids, etc. Though, it does increase the chance of error as someone = may mistype the client identifiers or fail to update the server before = rebooting the client. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted Lemon Sent: Thursday, January 29, 2004 4:52 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] RE: draft-ietf-dhc-3315id-for-v4-01.txt On Jan 29, 2004, at 3:02 PM, Ralph Droms wrote: > Looks to me like we're waiting for a new > revision to continue the discussion. That's right. Also, I published an individual submission that I'd=20 like the WG to consider before Seoul. This is about a related issue. =20 I haven't brought it up yet because I wanted to bring it up in=20 connection with a discussion about the -02 version of the 3315id draft,=20 which I haven't yet had time to prepare. :'/ _______________________________________________ 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 Jan 30 11:16:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23966; Fri, 30 Jan 2004 11:16: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 1AmbJK-0003br-FD; Fri, 30 Jan 2004 11:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbJ1-0003AW-Gw for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 11:15: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 LAA23915 for ; Fri, 30 Jan 2004 11:15:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmbJ0-0000po-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 11:15:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmbHb-0000iZ-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 11:14:15 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AmbGg-0000b3-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 11:13:18 -0500 Received: from [10.0.0.12] (cs241750-189.austin.rr.com [24.175.0.189]) by toccata.fugue.com (Postfix) with ESMTP id C119C2A99E6; Fri, 30 Jan 2004 10:04:05 -0600 (CST) In-Reply-To: <000001c3e744$45c8dd50$6401a8c0@BVolz> References: <000001c3e744$45c8dd50$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <35FA5802-533F-11D8-ADDC-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] RE: draft-ietf-dhc-3315id-for-v4-01.txt Date: Fri, 30 Jan 2004 10:13:16 -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 Jan 30, 2004, at 9:18 AM, Bernie Volz wrote: > I assume you refer to draft-lemon-dhcpv4-to-v6-id-trans-00.txt. I > reviewed > it quickly and is this pain really worth it just to change your > identifier? > I doubt it. Many identifiers are derived from NIC addresses and few > think > twice about changing that hardware ... you just go with a new address. Right, that was my thinking too. I wrote it up because there was some demand for a solution, but I think the demand was uninformed, and this draft should help people to understand just what a pain in the neck it would be to define a formal transition procedure. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 12:59:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04467; Fri, 30 Jan 2004 12:59: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 1Amcuz-0006rD-8J; Fri, 30 Jan 2004 12: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 1AmcuM-0006pz-UE for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 12:58: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 MAA04376 for ; Fri, 30 Jan 2004 12:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmcuL-0003Dv-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 12:58:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmctO-00033O-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 12:57:22 -0500 Received: from smtp101.mail.sc5.yahoo.com ([216.136.174.139]) by ietf-mx with smtp (Exim 4.12) id 1AmcsP-0002sN-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 12:56:21 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.145 with login) by smtp101.mail.sc5.yahoo.com with SMTP; 30 Jan 2004 17:56:20 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Subject: FW: [dhcwg] Discussion of DHCP implementation issues Date: Fri, 30 Jan 2004 10:00:19 -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 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 -----Original Message----- From: Barr Hibbs [mailto:rbhibbs@pacbell.net] Sent: Friday, January 30, 2004 09:59 To: Ralph Droms Subject: RE: [dhcwg] Discussion of DHCP implementation issues Yes, I'd like to participate in the conference call. I'm in the Pacific timezone, and would prefer the conference call to be between 12 noon and 5 pm Eastern Time. Goals: 1. Get sufficient closure on major points of the draft that an "-02" draft can be created following the Working Groups meeting in Seoul. 2. Do we have sufficient response from the community to proceed? 3. Identify editors to incorporate proposed changes into an RFC2131bis document. 4. Determine interest in a full review of RFC2132 and other current RFCs involving the DHCPv4 protocol and options. Agenda Items: 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 and other current RFCs --Barr > At the WG meeting in Minneapolis, the WG reviewed > draft-ietf-dhc-implementation-01.txt. During the review, the WG > decided to hold a conference call and possibly a workshop to come to > closure on the various issues in draft-ietf-dhc-implementation-01.txt. > I'd like to schedule the conf call for the week of 2/23 (the week > before the IETF meeting in Seoul). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 13:02:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04744; Fri, 30 Jan 2004 13:02: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 1Amcxu-0007Ce-4K; Fri, 30 Jan 2004 13: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 1AmcxL-0007AL-7k for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 13:01: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 NAA04631 for ; Fri, 30 Jan 2004 13:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmcxJ-0003jq-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 13:01:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmcwK-0003ZM-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 13:00:25 -0500 Received: from smtp103.mail.sc5.yahoo.com ([66.163.169.222]) by ietf-mx with smtp (Exim 4.12) id 1AmcvX-0003QK-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 12:59:35 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.145 with login) by smtp103.mail.sc5.yahoo.com with SMTP; 30 Jan 2004 17:59:34 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] Extending the set of available DHCP option codes Date: Fri, 30 Jan 2004 10:03:34 -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: <4.3.2.7.2.20040129154925.02b51c88@flask.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=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 While I agree that the selection of option (1) gives us the greatest immediate and long-term benefit for DHCPv4, I still believe we should pursue reclamation of additional option codes per the misunderstanding expressed as option (2). --Barr > At the WG meeting in Minneapolis, the WG accepted two mechanisms for > extending the set of available DHCP option codes from > draft-ietf-dhc-extended-optioncodes-00.txt: > > (1) redesignate option codes 128-223 to be assigned to new options > (2) recover disused option codes (the "Impress Server" option being > the canonical example) for reassignment to new options > > It turns out we misunderstood the second of these two mechanisms; the > author of draft-ietf-dhc-extended-optioncodes-00.txt (Bernie Volz) was > referring to option codes already under consideration for reclamation in > "Unused Dynamic Host Configuration Protocol (DHCP) Option Codes" > (RFC 3679), rather than option codes defined in RFC 2132 that currently > see little use. > > Therefore, we should not follow up on (2) and will pursue only (1) > (which is now published as draft-ietf-dhc-reclassify-options-00). > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 13:52:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08243; Fri, 30 Jan 2004 13:52: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 1AmdkI-0006Uv-OW; Fri, 30 Jan 2004 13:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdjz-0005kV-OU for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 13:51: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 NAA08201 for ; Fri, 30 Jan 2004 13:51:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amdjx-0003TN-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 13:51:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amdiz-0003K1-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 13:50:42 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AmdiU-0003AJ-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 13:50:10 -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 i0UIo157087948; Fri, 30 Jan 2004 13:50:09 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , Subject: RE: [dhcwg] Extending the set of available DHCP option codes Date: Fri, 30 Jan 2004 13:50:00 -0500 Message-ID: <000001c3e761$e085e0a0$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: 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 Barr: If you'd like to work on this, please feel free to initiate that effort = (in conjunction with RFC2131bis there should be a RFC2132bis?). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Barr Hibbs Sent: Friday, January 30, 2004 1:04 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] Extending the set of available DHCP option codes While I agree that the selection of option (1) gives us the greatest immediate and long-term benefit for DHCPv4, I still believe we should = pursue reclamation of additional option codes per the misunderstanding = expressed as option (2). --Barr > At the WG meeting in Minneapolis, the WG accepted two mechanisms for > extending the set of available DHCP option codes from > draft-ietf-dhc-extended-optioncodes-00.txt: > > (1) redesignate option codes 128-223 to be assigned to new options > (2) recover disused option codes (the "Impress Server" option being > the canonical example) for reassignment to new options > > It turns out we misunderstood the second of these two mechanisms; the > author of draft-ietf-dhc-extended-optioncodes-00.txt (Bernie Volz) was > referring to option codes already under consideration for reclamation = in > "Unused Dynamic Host Configuration Protocol (DHCP) Option Codes" > (RFC 3679), rather than option codes defined in RFC 2132 that = currently > see little use. > > Therefore, we should not follow up on (2) and will pursue only (1) > (which is now published as draft-ietf-dhc-reclassify-options-00). > _______________________________________________ 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 Jan 30 16:55:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03885; Fri, 30 Jan 2004 16:55: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 1AmgbR-0004UO-5D; Fri, 30 Jan 2004 16:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amgaq-0004RB-1x for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 16: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 QAA02536 for ; Fri, 30 Jan 2004 16:54:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amgan-0005iw-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 16:54:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgZt-0005Xo-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 16:53:29 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AmgZ3-0005Ek-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 16:52:37 -0500 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 i0ULq3Va025948; Fri, 30 Jan 2004 16:52:04 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-3.cisco.com [10.86.240.3]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFR76948; Fri, 30 Jan 2004 16:52:02 -0500 (EST) Message-Id: <4.3.2.7.2.20040130161647.01eda2c8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Jan 2004 16:51:59 -0500 To: "" From: Ralph Droms Subject: Re: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt Cc: "Mats Jonsson" , "" In-Reply-To: <200401301313.i0UDD8A08896@cichlid.raleigh.ibm.com> References: 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: , Speaking with my Cisco hat on, rather than my WG chair hat... The two examples from Cisco that Thomas has chosen to point out are referenced in two IPR statements at: http://ietf.org/ietf/IPR/CISCO-8021X.txt http://ietf.org/ietf/IPR/cisco-ipr-draft-ietf-dhc-server-override.txt These IPR statements are essentially identical to IPR statements from other vendors regarding DHCP and many other protocols (see http://ietf.org/ipr.html). Cisco has never asked for royalties in the past. We have made IPR claims related to these IPR statements to ensure that the relevant IP stays publicly available. The IETF has no precedent for requiring, asking for or publishing any other form of royalty statement ("RAND-Z"), so I don't see any reason to hold these particular examples up as problematic. - Ralph, who will now go back to being WG chair At 08:13 AM 1/30/2004 -0500, Thomas Narten wrote: > > The only standard in the DHCwg that contains any patented IP (that I > > know of) is the relay agent information option draft, and to the best > > of my recollection Motorola stated that they would not demand any > > compensation from software or hardware manufacturers who implement > > RFC3046, other than in cases where there might be cross-licensing > > issues. > >To be clear, Motorola's statement is here: > >http://www.ietf.org/ietf/IPR/MOTOROLA-DHCP-AGENT-OPTIONS > >Also, to be fair, there have been other assertions of IPR on DHC work >items, though they are not RFCs yet. > >See Section 10 of draft-ietf-dhc-agentopt-radius-03.txt, for which a >WG Last Call has completed. > >And see also Section 10 of draft-ietf-dhc-subnet-alloc-00.txt (though >expired), which I presume relates to >http://www.ietf.org/ietf/IPR/CISCO-raj-dhc-subnet-alloc.txt. > >Thomas > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 17:01:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11009; Fri, 30 Jan 2004 17:01:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmghC-0005LS-8n; Fri, 30 Jan 2004 17:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amggu-0005Hj-0G for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 17:00: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 RAA10022 for ; Fri, 30 Jan 2004 17:00:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amggr-0006ja-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 17:00:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amgfx-0006Z8-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 16:59:46 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AmgfQ-0006QE-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 16:59:12 -0500 Received: from [10.0.1.102] (cs241750-72.austin.rr.com [24.175.0.72]) by toccata.fugue.com (Postfix) with ESMTP id D24DC2A9C4B; Fri, 30 Jan 2004 15:49:54 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040130161647.01eda2c8@flask.cisco.com> References: <4.3.2.7.2.20040130161647.01eda2c8@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <847036B3-536F-11D8-ADDC-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: "" , "Mats Jonsson" , "" From: Ted Lemon Subject: Re: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt Date: Fri, 30 Jan 2004 15:59:03 -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.5 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 Jan 30, 2004, at 3:51 PM, Ralph Droms wrote: > The IETF has no precedent for > requiring, asking for or publishing any other form of royalty statement > ("RAND-Z"), so I don't see any reason to hold these particular > examples up > as problematic. The Motorola agent-options statement specifically disclaims royalties other than in cases of cross-licensing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 17:30:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14762; Fri, 30 Jan 2004 17:30: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 1Amh9I-00080X-AG; Fri, 30 Jan 2004 17:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amh8t-0007xg-7k for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 17:29: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 RAA13626 for ; Fri, 30 Jan 2004 17:29:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amh8q-0003dj-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 17:29:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amh7y-0003SR-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 17:28:43 -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 1Amh7C-0003Dg-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 17:27:54 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 30 Jan 2004 14:32:41 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0UMRLsf016827; Fri, 30 Jan 2004 14:27:22 -0800 (PST) Received: from jschnizl-w2k.cisco.com (sjc-vpn2-300.cisco.com [10.21.113.44]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA22034; Fri, 30 Jan 2004 14:27:20 -0800 (PST) Message-Id: <4.3.2.7.2.20040130170926.022b4d68@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Jan 2004 17:27:18 -0500 To: Ted Lemon From: John Schnizlein Subject: Re: [dhcwg] Regarding Draft-ietf-dhc-subscriber-id-X.txt Cc: Ralph Droms , "" , "Mats Jonsson" , "" In-Reply-To: <847036B3-536F-11D8-ADDC-000A95D9C74C@nominum.com> References: <4.3.2.7.2.20040130161647.01eda2c8@flask.cisco.com> <4.3.2.7.2.20040130161647.01eda2c8@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.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 am not a lawyer, but the plain-English meaning of "This grant immediately cancels to any party asserting rights against Motorola for a method or methods described in the draft." is not limited to cross-licensing. While the Cisco lawyer did not use exactly the same phrasing, he has explained to me that this is essentially the same as our statement. Robert Barr , is the Cisco contact point for these IPR issues. To make it clear that the above quote is not out of context, I have included the entire statement below. ________________________________ The following was received September 25, 1999 From: Kirk.Dailey@motorola.com To: Mr. Steve Coya, Internet Engineering Task Force scoya@ietf.org Re: Motorola Patent Application for DHCP Relay Agent Options This is to inform the IETF that in the event that Motorola is granted a patent or patents essential to the implementation of the internet draft , Motorola agrees to grant a royalty-free license to all parties implementing the draft, subject to reciprocity of the licensed party. This grant immediately cancels to any party asserting rights against Motorola for a method or methods described in the draft. Inquiries are directed to Mr. Kirk Dailey, Kirk.Daily@motorola.com. At 04:59 PM 1/30/2004, Ted Lemon wrote: >The Motorola agent-options statement specifically disclaims royalties other than in cases of cross-licensing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 30 18:13:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02134; Fri, 30 Jan 2004 18:13: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 1Amhor-0005s6-Cv; Fri, 30 Jan 2004 18: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 1AmhoM-0005k5-6s for dhcwg@optimus.ietf.org; Fri, 30 Jan 2004 18:12: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 SAA01190 for ; Fri, 30 Jan 2004 18:12:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmhoJ-0000s6-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 18:12:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmhnL-0000lW-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 18:11:27 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AmhmK-0000aq-00 for dhcwg@ietf.org; Fri, 30 Jan 2004 18:10:24 -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 i0UNAL57061152 for ; Fri, 30 Jan 2004 18:10:24 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Dhcwg'" Subject: RE: [dhcwg] Discussion of DHCP implementation issues Date: Fri, 30 Jan 2004 18:10:23 -0500 Message-ID: <000101c3e786$3d3a7120$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Barr goals / agenda seem very good and I'm interested in participating. I'm in the Eastern time-zone and fairly open as to time (9 AM - 9 PM ET). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Barr Hibbs Sent: Friday, January 30, 2004 1:00 PM To: Dhcwg Subject: FW: [dhcwg] Discussion of DHCP implementation issues -----Original Message----- From: Barr Hibbs [mailto:rbhibbs@pacbell.net] Sent: Friday, January 30, 2004 09:59 To: Ralph Droms Subject: RE: [dhcwg] Discussion of DHCP implementation issues Yes, I'd like to participate in the conference call. I'm in the Pacific timezone, and would prefer the conference call to be between 12 noon and 5 pm Eastern Time. Goals: 1. Get sufficient closure on major points of the draft that an "-02" draft can be created following the Working Groups meeting in Seoul. 2. Do we have sufficient response from the community to proceed? 3. Identify editors to incorporate proposed changes into an RFC2131bis document. 4. Determine interest in a full review of RFC2132 and other current RFCs involving the DHCPv4 protocol and options. Agenda Items: 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 and other current RFCs --Barr > At the WG meeting in Minneapolis, the WG reviewed > draft-ietf-dhc-implementation-01.txt. During the review, the WG > decided to hold a conference call and possibly a workshop to come to > closure on the various issues in draft-ietf-dhc-implementation-01.txt. > I'd like to schedule the conf call for the week of 2/23 (the week > before the IETF meeting in Seoul). _______________________________________________ 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 Jan 31 09:34:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22139; Sat, 31 Jan 2004 09: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 1AmwC9-0000Eq-Rr; Sat, 31 Jan 2004 09: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 1AmwC8-0000ER-AC for dhcwg@optimus.ietf.org; Sat, 31 Jan 2004 09:34:00 -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 JAA22102 for ; Sat, 31 Jan 2004 09:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmwC6-0000c5-00 for dhcwg@ietf.org; Sat, 31 Jan 2004 09:33:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmwB8-0000U9-00 for dhcwg@ietf.org; Sat, 31 Jan 2004 09:32:59 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1AmwAB-0000NX-00 for dhcwg@ietf.org; Sat, 31 Jan 2004 09:31:59 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel8.hp.com (Postfix) with ESMTP id 8B84D1C0109C; Sat, 31 Jan 2004 09:31:57 -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 i0VEGVZ03153; Sat, 31 Jan 2004 19:46:31 +0530 (IST) Message-ID: <401BBC40.9070800@india.hp.com> Date: Sat, 31 Jan 2004 20:01:28 +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] Discussion of DHCP implementation issues References: <4.3.2.7.2.20040129160545.01f01008@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040129160545.01f01008@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 Hi Ralph I would like to attend the meeting. I am in IST timezone. The preferreble time is either 2/23, 10 PM to 12 PM IST or 2/24, 6:00 AM to 9:00 AM IST As of now, the main item I wold like to be added is, Obsolete sname and fname in the header, option 66, 67 Vijay Ralph Droms wrote: > At the WG meeting in Minneapolis, the WG reviewed > draft-ietf-dhc-implementation-01.txt. During the review, the WG > decided to > hold a conference call and possibly a workshop to come to closure on the > various issues in draft-ietf-dhc-implementation-01.txt. I'd like to > schedule the conf call for the week of 2/23 (the week before the IETF > meeting in Seoul). To begin organizing the call, please respond to the > dhcwg list with: > > * an indication if you are interested in joining the call > * your timezone and available times > * goals for the meeting > * specific agenda items > > - 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