From owner-dhcp-v6@bucknell.edu Fri Dec 1 10:20:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20329; Fri, 1 Dec 2000 10:20:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB1FHJO23833; Fri, 1 Dec 2000 10:17:19 -0500 (EST) Received: from zcamail02.zca.compaq.com (zcamail02.zca.compaq.com [161.114.32.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB1FH4O15814 for ; Fri, 1 Dec 2000 10:17:05 -0500 (EST) Received: by zcamail02.zca.compaq.com (Postfix, from userid 12345) id E6A5F73E3; Fri, 1 Dec 2000 07:16:55 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail02.zca.compaq.com (Postfix) with ESMTP id 697A875AE for ; Fri, 1 Dec 2000 07:16:55 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id KAA0000690048; Fri, 1 Dec 2000 10:16:30 -0500 (EST) From: Jim Bound Message-Id: <200012011516.KAA0000690048@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: -16 rev of DHCPv6 spec In-reply-to: Your message of "Tue, 28 Nov 2000 10:36:09 EST." <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> Date: Fri, 01 Dec 2000 10:16:30 -0500 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Bernie, Thanks for the careful read and great input. I am traveling alot this week again so can't respond in details but talking with Ralph and Mike consistently. But do want to suggest a response to one of your points. Can discuss further on design tele conference next week. >- In most of the message headers, there is the 16-byte client-link-local >address. What about dropping the first 64-bits of this (the prefix)? It >would save 8-bytes/packet. This is just a thought - there might be good >reasons NOT to do this. But on the other hand, it would remove the need for >servers/relays to validate that the prefix is the link local - instead, they >pre-append the prefix when they need to use it as a link-local address. So, >if we were to do this, we'd call this 64-bit field "interface ID" or >something similar (at least based on RFC 2373 terminology). > >>From RFC 2373, it appears that link local doesn't really consume the full >64-bits before the interface-id, instead only the first 10 bits are really >specified (with the next 54-bits being zero, though it is not clear that is >REQUIRED). > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ If I understand what your suggesting?, we cannot do what you ask. The reason is that we cannot assume in any IETF protocol the "interface ID" will always be 64bytes for all RFC 2373 prefixes. I thought this to some years ago as I wanted to only carry 64byte prefixes in our internal OS inpcb structures for IPv6 in the kernel for fast lookups and for host routing path search. But, then I would have to have if-condition construct for the Format-Prefix for IPv6 addresses. See below from RFC 2373: --------------------------- 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique on that link. They may also be unique over a broader scope. In many cases an interface's identifier will be the same as that interface's link- layer address. The same interface identifier may be used on multiple interfaces on a single node. Note that the use of the same interface identifier on multiple interfaces of a single node does not affect the interface identifier's global uniqueness or each IPv6 addresses global uniqueness created using that interface identifier. In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]. EUI-64 based Interface identifiers may have global scope when a global token is available (e.g., IEEE 48bit MAC) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). It is required that the "u" bit (universal/local bit in IEEE EUI-64 terminology) be inverted when forming the interface identifier from the EUI-64. The "u" bit is set to one (1) to indicate global scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an EUI-64 identifier are as follows: 0 0 0 1 1 2 |0 7 8 5 6 3| +----+----+----+----+----+----+ |cccc|ccug|cccc|cccc|cccc|cccc| +----+----+----+----+----+----+ ----------------------------------------------- The key is the sentence in the above paragraph first sentence "In a number of format prefixes"......Not all IPv6 Format Prefixes will have just 64byte interface ids. Does this resolve your suggestion? thanks /jim From owner-dhcp-v6@bucknell.edu Fri Dec 1 11:14:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03976; Fri, 1 Dec 2000 11:14:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB1GBVO15436; Fri, 1 Dec 2000 11:11:31 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB1GBHO06197 for ; Fri, 1 Dec 2000 11:11:17 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 11:11:02 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE8603607458@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Date: Fri, 1 Dec 2000 11:11:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Jim: Yes I think it does clearly resolve the issue (use all 128 bits). - Bernie -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Friday, December 01, 2000 10:17 AM To: DHCPv6 discussion list Cc: bound@zk3.dec.com Subject: Re: -16 rev of DHCPv6 spec Hi Bernie, Thanks for the careful read and great input. I am traveling alot this week again so can't respond in details but talking with Ralph and Mike consistently. But do want to suggest a response to one of your points. Can discuss further on design tele conference next week. >- In most of the message headers, there is the 16-byte client-link-local >address. What about dropping the first 64-bits of this (the prefix)? It >would save 8-bytes/packet. This is just a thought - there might be good >reasons NOT to do this. But on the other hand, it would remove the need for >servers/relays to validate that the prefix is the link local - instead, they >pre-append the prefix when they need to use it as a link-local address. So, >if we were to do this, we'd call this 64-bit field "interface ID" or >something similar (at least based on RFC 2373 terminology). > >>From RFC 2373, it appears that link local doesn't really consume the full >64-bits before the interface-id, instead only the first 10 bits are really >specified (with the next 54-bits being zero, though it is not clear that is >REQUIRED). > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ If I understand what your suggesting?, we cannot do what you ask. The reason is that we cannot assume in any IETF protocol the "interface ID" will always be 64bytes for all RFC 2373 prefixes. I thought this to some years ago as I wanted to only carry 64byte prefixes in our internal OS inpcb structures for IPv6 in the kernel for fast lookups and for host routing path search. But, then I would have to have if-condition construct for the Format-Prefix for IPv6 addresses. See below from RFC 2373: --------------------------- 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique on that link. They may also be unique over a broader scope. In many cases an interface's identifier will be the same as that interface's link- layer address. The same interface identifier may be used on multiple interfaces on a single node. Note that the use of the same interface identifier on multiple interfaces of a single node does not affect the interface identifier's global uniqueness or each IPv6 addresses global uniqueness created using that interface identifier. In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]. EUI-64 based Interface identifiers may have global scope when a global token is available (e.g., IEEE 48bit MAC) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). It is required that the "u" bit (universal/local bit in IEEE EUI-64 terminology) be inverted when forming the interface identifier from the EUI-64. The "u" bit is set to one (1) to indicate global scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an EUI-64 identifier are as follows: 0 0 0 1 1 2 |0 7 8 5 6 3| +----+----+----+----+----+----+ |cccc|ccug|cccc|cccc|cccc|cccc| +----+----+----+----+----+----+ ----------------------------------------------- The key is the sentence in the above paragraph first sentence "In a number of format prefixes"......Not all IPv6 Format Prefixes will have just 64byte interface ids. Does this resolve your suggestion? thanks /jim From owner-dhcp-v6@bucknell.edu Fri Dec 1 14:57:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06825; Fri, 1 Dec 2000 14:57:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB1JbRO21298; Fri, 1 Dec 2000 14:37:27 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB1JbCO31749 for ; Fri, 1 Dec 2000 14:37:12 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27014 for ; Fri, 1 Dec 2000 11:37:02 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB1Jb7327021 for ; Fri, 1 Dec 2000 11:37:07 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA03253 for ; Fri, 1 Dec 2000 11:36:53 -0800 (PST) Message-Id: <4.3.1.2.20001201143050.00b104f0@localhost> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 01 Dec 2000 14:36:55 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Design team teleconference - last call for participation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have scheduled another design team teleconference for 12/5, 12noon-3PM EST. The purpose of this teleconference is to discuss the changes in the -16 rev, with the goal of identifying and resolving as many outstanding issues as possible. The results of the teleconference will be reported at the WG meeting in San Diego. Any unresolved issues from the teleconference will be discussed during the WG meeting. You can get more information about the -16 rev and the teleconference at http://www.dhcp.org/dhcpv6-stat.html Cisco Systems is happy to host the design team teleconference in Chelmsford, MA. In addition to a conference room in Chelmsford, we will have conference call capability to accommodate those who can't attend in person. and will be happy to reimburse those outside the U.S. for their calls. If you want to participate in the call on 12/5, please contact me for the phone number and conference ID. I will be travelling Monday and may not be able to answer last minute requests to join the teleconference, so please contact me today if you haven't already done so. - Ralph From owner-dhcp-v6@bucknell.edu Tue Dec 5 04:23:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09687; Tue, 5 Dec 2000 04:23:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB59JZO02846; Tue, 5 Dec 2000 04:19:35 -0500 (EST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB59JQO24305 for ; Tue, 5 Dec 2000 04:19:26 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel1.hp.com (Postfix) with ESMTP id 9BA01E95 for ; Tue, 5 Dec 2000 01:19:23 -0800 (PST) Received: from india.hp.com (vijayak@dce.india.hp.com [15.10.45.122]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id OAA06792 for ; Tue, 5 Dec 2000 14:47:53 +0530 (IST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3A2CB373.2FDFC2E8@india.hp.com> Date: Tue, 05 Dec 2000 14:50:52 +0530 From: vijaya bhaskar Organization: hp ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: DHCPv6 Issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: vijayak@india.hp.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello Ralph, My name is Vijay. I am working with Hewlett-Packard India in HP-UX lab. I am working on DHCP. I, along with my colleague Jitesh, will be attending to the teleconf. We have the following implementation issues : 1. What would happen if there are multiple relays present in the same link and all of them transmit packets from the same server? Would there be a problem currently? 2. By what mechanism will the client talk to the application layer? 3. What authentiactions needs to be supported? What happens if the client supports it and the server does not? Could you please include these issues in the discussion? Thanks & regards, Vijay. From owner-dhcp-v6@bucknell.edu Wed Dec 6 07:19:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22354; Wed, 6 Dec 2000 07:19:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB6CDcO04610; Wed, 6 Dec 2000 07:13:38 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB6CDMO16324; Wed, 6 Dec 2000 07:13:22 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA18916; Wed, 6 Dec 2000 04:13:09 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB6CDIt23754; Wed, 6 Dec 2000 04:13:18 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA27115; Wed, 6 Dec 2000 04:13:05 -0800 (PST) Message-Id: <4.3.1.2.20001206070946.00c41d50@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 06 Dec 2000 07:12:58 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Updated agendas for DHC WG meetings in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN FYI (also available at http://www.dhcp.org/0012-meeting.html with links to I-Ds)... ===== 12/11, 0900-1130 - DHCPv4 agenda items -------------------------------------- DHC WG activities update Ralph Droms, 15 minutes DHCP Option for PacketCable Burcak Beser, 15 minutes VoIP Client Configuration DHCP failover protocol Kim Kinnear, 15 minutes DHCP Lease Query Kim Kinnear, 15 minutes Addition of Device Class Rich Woundy, 15 minutes to Agent Options Dynamic Host Configuration Barr Hibbs, 10 minutes Protocol (DHCP) Server MIB DHC Load Balancing Algorithm Bernie Volz, 10 minutes The Classless Static Route Ted Lemon, 15 minutes Option for DHCP DHCP Domain Search Option Bernard Aboba, 15 minutes 12/12, 0900-1130 - DHCPv6 spec review ------------------------------------- Dynamic Host Configuration Mike Carney Protocol for IPv6 (DHCPv6) Jim Bound Charlie Perkins Ralph Droms From owner-dhcp-v6@bucknell.edu Wed Dec 6 12:58:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02010; Wed, 6 Dec 2000 12:58:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB6HrrO01793; Wed, 6 Dec 2000 12:53:53 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB6HrjO09801 for ; Wed, 6 Dec 2000 12:53:45 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA19516 for ; Wed, 6 Dec 2000 12:53:27 -0500 (EST) Message-Id: <4.3.1.2.20001206124002.00c44100@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 06 Dec 2000 12:53:41 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: WG meeting, 12/12 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN If you plan to attend next week's WG meeting... The -16 rev of the DHCPv6 spec is *significantly* different from the -15 rev. One major change is that the spec is currently documented in a single I-D, http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-16.txt The changes in rev -16 are summarized in section 23. The WG members contributing to the draft have held two teleconferences since the last WG meeting in Pittsburgh. During the first teleconference, we generated a list of issues that were addressed in the most recent rev of the I-D. In the second teleconference (on 12/5), we reviewed some remaining issues from the -16 draft and developed a list of issues to bring to the WG. Summaries of those meetings are available at http://www.dhcp.org You *must* read the -16 rev of the draft before contributing to the WG discussion next Tuesday. We will move *very* fast through the changes in the -16 draft and the issues discussed in the 12/5 teleconference, to gauge WG consensus on the draft and proposed solutions to some outstanding issues. We will also discuss a couple of outstanding issues - most notably the design and use of UUIDs and the options to be included in the base spec I-D. - Ralph From owner-dhcp-v6@bucknell.edu Fri Dec 8 11:34:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07916; Fri, 8 Dec 2000 11:34:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB8GU0O11283; Fri, 8 Dec 2000 11:30:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB8GToO05967 for ; Fri, 8 Dec 2000 11:29:50 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20937 for ; Fri, 8 Dec 2000 11:29:34 -0500 (EST) Message-Id: <4.3.1.2.20001208112719.00b31e40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 08 Dec 2000 11:29:50 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Agenda preview Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Look at http://www.dhcp.org/DHCPv6-slides/index.html to preview the slides from the DHC WG meeting on DHCPv6 scheduled for next Tuesday, 12/12. We're going to go through the slides from the 8/31 teleconference quickly, so you'll have a better chance of keeping up if you can review those slides before the 12/12 meeting... - Ralph Droms From owner-dhcp-v6@bucknell.edu Fri Dec 8 16:03:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24672; Fri, 8 Dec 2000 16:03:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB8KxbO03891; Fri, 8 Dec 2000 15:59:37 -0500 (EST) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB8KxIO03779 for ; Fri, 8 Dec 2000 15:59:18 -0500 (EST) Received: by alfa.itea.ntnu.no id VAA0000015593; Fri, 8 Dec 2000 21:59:16 +0100 (MET) From: Stig Venås Date: Fri, 8 Dec 2000 21:59:16 +0100 To: DHCPv6 discussion list Subject: Re: -16 rev of DHCPv6 spec Message-ID: <20001208215916.A20355@itea.ntnu.no> References: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com>; from Volz@ipworks.com on Tue, Nov 28, 2000 at 10:36:09AM -0500 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've finally read the draft and have some comments as well. On Tue, Nov 28, 2000 at 10:36:09AM -0500, Bernie Volz wrote: > Ralph and others ... here's some comments on the -16 spec. > > In general, this looks GREAT! Excellent job! Yes > - Section 22.2's diagram has a "pref. len". Yet this field is not defined > anywhere in the list of fields. Was this an error in the diagram? Or was > this to be the "prefix length"? If pref. len is prefix length, you might > want to consider what to use as an abbreviation since then pref. could be > "prefix" or "preferred" (as in preferred lifetime). I think it must be prefix len, but I agree, the abbreviation is no good. > - In section 10.3.3, there are several mentions of "advertising availability > of IP address" ... how is this done (perhaps there will or is an option that > will provide this information?). Also, if this capability DOES exist, isn't > Ted's Discussion point in section 10.5.2 null and void? My thought too. I think such an option is a good idea, but it requires an option not specified in the draft as I understand it. One more thing. It says several places that an IA is identified by (prefix, UUID), why isn't the UUID enough? The 64 bits UUID should be enough on it's own I would think. There are also situations where I don't understand how the server knows the prefix, I think things would be much simpler if the UUID were enough on it's own. In order to do this, the IA UUID would have to be decided by the server though, or one has to make sure two clients won't use the same UUID in requests to the same server. If one uses (prefix, UUID) the server must always know the prefix when it gets an IA (don't think this is the case now), and one must also make sure two clients won't try to use same (prefix, UUID) pair. I haven't had time to think about all the details yet, my apologies if I have missed something vital. Stig From owner-dhcp-v6@bucknell.edu Mon Dec 11 01:35:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22830; Mon, 11 Dec 2000 01:35:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBB6V4929261; Mon, 11 Dec 2000 01:31:04 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBB6Up904585 for ; Mon, 11 Dec 2000 01:30:51 -0500 (EST) Received: from rdroms-nt.cisco.com (rtp-vpn-28.cisco.com [10.82.192.28]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA17230; Mon, 11 Dec 2000 01:30:27 -0500 (EST) Message-Id: <4.3.1.2.20001210191146.00b35530@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 10 Dec 2000 19:18:14 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: -16 rev of DHCPv6 spec In-Reply-To: <20001208215916.A20355@itea.ntnu.no> References: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id eBB6Uq914648 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN X-MIME-Autoconverted: from 8bit to quoted-printable by mail.bucknell.edu id eBB6V4929261 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA22830 At 09:59 PM 12/8/00 +0100, Stig Venås wrote: >I've finally read the draft and have some comments as well. > >On Tue, Nov 28, 2000 at 10:36:09AM -0500, Bernie Volz wrote: > > > In general, this looks GREAT! Excellent job! > >Yes Thanks... > > - Section 22.2's diagram has a "pref. len". Yet this field is not defined > > anywhere in the list of fields. > >I think it must be prefix len, but I agree, the abbreviation is no good. The "prefix length" field was left out of the list of fields (editor's oversight). I will label the field "prefix length" and add a description of the field to the list of fields. > > - In section 10.3.3, there are several mentions of "advertising > availability > > of IP address" ... how is this done (perhaps there will or is an option > that > > will provide this information?). Also, if this capability DOES exist, isn't > > Ted's Discussion point in section 10.5.2 null and void? > >My thought too. I think such an option is a good idea, but it requires >an option not specified in the draft as I understand it. Sorry about the confusion. We have confirmed (in the 12/5 meeting) that carrying addresses in the Advertise is the right thing to do. The details are TBD. I *imagine* the right thing to do is for the client to pass the IAs it needs configurations for in the Solicit. The server can then fill in the IAs and return them to the client in the Advertise. >One more thing. > >It says several places that an IA is identified by (prefix, UUID), why >isn't the UUID enough? We also had this conversation during the 12/5 teleconference and will bring the discussion to the WG on Tuesday, 12/12. - Ralph From owner-dhcp-v6@bucknell.edu Tue Dec 19 22:32:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03023; Tue, 19 Dec 2000 22:32:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBK3Sa929582; Tue, 19 Dec 2000 22:28:37 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBK3SL928710 for ; Tue, 19 Dec 2000 22:28:21 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Dec 2000 18:26:00 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 18:26:43 -0800 (Pacific Standard Time) Received: from DF-SCOOBY.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 19 Dec 2000 18:26:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Progress on the DHCPv6 draft in SanDiego IETF meeting Date: Tue, 19 Dec 2000 18:26:40 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A6819C53B@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: Progress on the DHCPv6 draft in SanDiego IETF meeting Thread-Index: AcBqLEi2sUObiKrdSxqLVQb/35+f2A== From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 20 Dec 2000 02:26:42.0782 (UTC) FILETIME=[4A86AFE0:01C06A2C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id eBK3SM911681 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Hi all, In the conference call a week prior to the IETF meeting, we managed to hash out several outstanding issues with the latest version of the DHCP draft. There were some issues that needed further discussion and clarification such as IA. I was wondering what progress was made in the San Diego IETF. Can some one share in this forum what was achieved in the SanDiego IETF and what else needs to be discussed further for the draft to move forward? thx, Thiru From owner-dhcp-v6@bucknell.edu Thu Dec 28 08:07:40 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15636; Thu, 28 Dec 2000 08:07:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBSD3c912097; Thu, 28 Dec 2000 08:03:39 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBSD3P912255; Thu, 28 Dec 2000 08:03:25 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA10173; Thu, 28 Dec 2000 05:03:14 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBSD39J23192; Thu, 28 Dec 2000 05:03:09 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA16046; Thu, 28 Dec 2000 05:02:44 -0800 (PST) Message-Id: <4.3.1.2.20001228075233.00b93ae0@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 28 Dec 2000 08:02:28 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Minutes from DHC WG meetings in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Included below is a draft of the minutes from the San Diego meetings. Please get back to me by the end of next week (1/5) if you have any additions, corrections or other questions. - Ralph ===== The DHC WG met twice in San Diego. The WG discussed DHCPv4 issues in the first meeting: Ralph Droms (chair) opened the meeting with a summary of recent WG activities and document publications: New RFCS: * Procedure for Defining New DHCP Options and Message Types (RFC2939) * The Name Service Search Option for DHCP (RFC2937) * The User Class Option for DHCP (RFC3004) * The Subnet Selection Option for DHCP (RFC3011) * DHCP Relay Agent Information Option (Accepted for Proposed Standard) I-D Actions and Status: * Authentication for DHCP Messages: republished; requires minor edits before submission for Proposed Standard * Dynamic host configuration : DHCP reconfigure extension: ready for submission for Proposed Standard; awaiting authentication draft * Several new drafts to be considered for WG action DHCPv6 Activities: * Teleconference 8/31 List of issues generated Solutions added to spec I-D Discussion on mailing list * -16 rev of I-D published * Teleconference 12/5 Issues in -16 rev Some solutions defined Some issues to be discussed in WG meeting * WG meeting on DHCPv6 12/12 DHCP Option for PacketCable VoIP Client Configuration Burcak Beser In packet cable equipment, there may be multiple personalities within a single device such as a VoIP device. Each personality may need a separate IP address and obtain that address through a different DHCP server. Beser's draft, draft-ietf-dhc-packetcable-01.txt, proposes a new option that would support the PacketCable standard for configuring a DHCP server in a packet cable device. The WG asked if it is necessary for packet cable devices to have an architecture with multiple personalities that is configured with a special option. Kim Kinnear clarified that this option will support the standard of another standards body (PacketCable) without mandating its use by all DHCp clients. There was another question about the use of unicast versus multicast, which was clarified by pointing out the the initially configured packet cable device can act as a relay agent for the second device and unicast messages directly to the second level DHCP server. Action item: Beser will redraft to clarify format of options. Droms will review use of option specific to packet cable devices with PacketCable standard. DHCP Lease Query Kim Kinnear Issues with current draft, draft-ietf-dhc-leasequery-00.txt: Security - Kinnear suggested configuration of server with list of acceptable queriers would be an acceptable solution. Bulk, subnet-basis query - Kinnear has investigated bulk queries, but s of the opinion that the extra complexity does not justify the efficiency gain. What has Cisco implemented - In response to query from Ted Lemon, Kinnear will post summary of current Cisco implementation to DHC WG mailing list. Lease query and failover - Bernie Volz suggested draft should discuss use of lease query with failover partners; Kinnear agreed to add text to the draft about failover. Reservation - Kinnear will add bit to message to explicitly identify reservations. Different message types - Lemon suggested new message types rather than ACK/NAK. Kinnear agreed to this change. Action items: Kinnear will revise draft according to changes discussed during WG meeting. WG will review new draft at next meeting (Minneapolis) and then draft will go to last call. DHCP failover protocol Kim Kinnear Kinnear discussed what changed in most recent draft, draft-ietf-dhc-failover-08.txt. Lemon suggested we do interoperability testing between two independent implementations. Richard Jones said he would have an implementation by late January. Action item: Draft to go to last call prior to Minneapolis (either -08 or -09 draft at authors' discretion). Addition of Device Class to Agent Options Rich Woundy Woundy describes a new relay agent suboption in draft-ietf-dhc-agentoptions-device-class-00.txt. The new suboption allows the relay agent to identify the device class to the DHCP server. Lemon pointed out that suboption code 3 should not be used and this option should be assigned suboption code 4. Action item: Author will resubmit and WG will review new draft. Dynamic Host Configuration Protocol (DHCP) Server MIB Glenn Waters Waters announced that the DHCP server MIB in draft-ietf-dhc-server-mib-05.txt will be reviewed by the MIB doctors and then will be ready for last call. Action item: Authors to submit draft to MIB doctors and then draft (revised if necessary) will got to last call. DHC Load Balancing Algorithm Bernie Volz Now at IESG for last call. The Classless Static Route Option for DHCP Ted Lemon Action items: Lemon to clarify draft. Revised draft then ready for last call. DHCP Domain Search Option Bernard Aboba Issue of DNS compression as "evil" was raised. In this option, because compression reference point is well-known (beginning of option), compression is not a problem. Action items: Lemon to write draft describing concatenation of DHCP options. Aboba to revise draft to reference Lemon doc. Domain Search Option draft then ready for last call. DHCP Authentication Via Kerberos V Ted Lemon Lemon opined that this draft is the Kerberos-based authentication scheme that is the most likely to be deployed. Droms suggested that a quick summary of the differences between this scheme and the Lalwaney-Smedvinsky scheme would be useful; Lalwaney-Smedvinsky draft has such a comparison. See notes on Lalwaney-Smedvinsky draft (below) for more information. Triggering AAA from DHCP Relay Agents George Tsirtsis This draft describes a mechanism in which relay agents use AAA to validate DHCP request. Draft triggered discussion about whether this issue is within DHC WG charter. WG consensus is that it *should* be. Action items: Author to revise and WG will consider draft. Droms to add AAA/DHCP interaction to WG charter. Kerberos V Authentication Mode for Uninitialized Clients Sasha Medvinsky The Lalwaney-Medvinsky scheme for Kerberos-based DHCP authentication involves the use of "Kerberos Proxy' that assists a Kerberos exchange before the DHCP message exchange. Action item: Authors of two Kerberos authentication drafts will meet to devise single scheme to bring to WG. The WG discussed DHCPv6 issues in the second meeting: * Recent protocol spec activities: - 8/31 teleconference - Publication of draft-ietf-dhc-dhcpv6-16.txt based on issues resolved in 8/31 teleconference - 12/5 teleconference The following people participated in the 8/31 teleconference: Ralph Droms, Mark Stapp, Rich Woundy, Michael Carney, Jim Bound, Bernie Volz, Richard Jones, Thomas Narten, Ted Lemon, Barr Hibbs, Bernard Aboba, Richard Johnson, Josh Littlefield, Subir Das, Tony McAuley, Franics DuPont The group identified the following changes to be made in DHCPv6 spec; Droms presented this list to the WG and the WG accepted the changes except where noted: Issue: Understanding spec requires reading two documents Solution: Combine protocol spec and definitions for options that are part of base protocol operation into single document Issue: Releasable resources defined in DHCPv6; only real example is IPv6 addresses Solution: Discard all references to releasable resources and refer only to IPv6 addresses WG discussion: What about IPv4 addresses? Should IPvn addresses be carried on;y in DHCPvn; i.e., a dual-stack client uses both DHCPv4 and DHCPv6? Issue: Address model needed to allow for multiple addresses on an interface, multiple interface, roaming client identification Solution: define "Identity Association" to be a labeled collection of addresses Outstanding issues: - How to label? - Semantics of address management WG discussion: Additional discussion reserved for end of WG meeting Issue: Client behavior for address lifetime extension undefined Solution: Added description of address lifetime extension through IAs, controlled by parameters T1 and T2 Issue: Cleaner and simpler message formats Solution: Redefined message headers; all messages share same header format Related: Servers no longer advertise prefixes WG discussion: What about prefix advertisements if not in a routed environment? Consensus in WG was that prefixes not needed in this case. Issue: What were called "options" in DHCPv4 are called "extensions" in DHCPv6 Solution: Rename "extensions" to be "options" Issue: Where appropriate, coordinate DHCPv4 and DHCPv6 options (e.g., option codes, data formats, specifications) Solution: TBD Issue: Reduce number of ways to release addresses Solution: Release message is only way to release addresses Issue: Simplify reconfiguration Solution: Use DHCPv4-style reconfiguration; include multicast reconfiguration with no reliability guarantees WG discussion: When using multicast reconfigure, should reconfigure message be multicast once or more than once. If the server has a list of the clients it is trying to reconfigure, the server can manage retransmission for reliability. However, if the clients are not using DHCP for address assignment (i.e., using DHCPINFORM-like function), server may not have a list of clients. In any event, clients must be able to detect duplicates and respond (or not respond) appropriately. To mitigate "multicast implosion" due to synchronized responses to multicast reconfigure messages, Erik Nordmark suggested including delay parameters in the reconfigure message. This new parameter would specify a random delay to be used by clients to spread out the responses sent to the server. Issue: Authentication Solution: Use DHCPv4-style authentication framework Issue: Relay agents function (carried forward from BOOTP) is cumbersome Solution: Use encapsulation, in which client message is carried as payload in relay agent message Issue: Clients unicast some messages and multicast others (on local link) Solution: Clients multicast Solicit and Request messages; are not required to explicitly learn of relay agents WG discussion: Consider control from server to require client to multicast all messages, which would enable relay agents to examine all client messages. Draft will be left as is; if all-multicast mode is desired, text will be drafted and added to the spec before last call Issue: Avoid stateful server operation so that correct server operation does not depend on XID Solution: Redefined message exchanges so that server always returns same reply to retransmitted client message Details of -16 Rev of Spec I-D * Implemented solutions from 8/32 teleconference * Published just before I-D cutoff * Lots of typos; report them off-line to rdroms@cisco.com There was another teleconference of 12/5 to discuss the 16 rev of the protocol spec. The following people participated in the 12/5 teleconference: Michael Carney, Jim Bound, Bernie Volz, Thomas Narten, Ted Lemon, Ralph Droms, Mark Stapp, Kim Kinnear, Matt Williamson, Mike Dooley, Vijaya Bhaskar Here is a list of issues and resolutions from the 12/5 teleconference; again with any WG discussion or outstanding issues: Issue: Definition of label for IA Solution: Define UUID - "Universally Unique IDentifier" for each client; client assigns label to each IA: (UUID, binding-id) Outstanding issues: How is UUID defined? How does server use UUID to identify an IA? Volz suggested the identifier should be called DUID - "DHCP Unique IDentifier". More discussion deferred to end of WG meeting. Issue: Should Advertise message include addresses and configuration parameters from server? Solution: Yes WG discussion: Jim Bound asked if DHCPv4 semantics, in which server must mark offered address for later assignment to the client, must be adhered to. Droms believes this is an implementation issue not specified in the DHCPv4 spec. Kinnear suggested that if the client explicitly wants the addresses from the Advertise message, there should be an option through which it can request those addresses. Issue: What additional options should be included in base protocol spec or in separate doc? Solution: - Base spec: Status code, DHCP operational parameters (timeouts, etc.) - Separate doc: DNS name, DNS search order, DNS servers, client class, vendor class, TFTP server, boot file name, static routes Outstanding issues: Base spec or separate doc? Others options? WG discussion: Kinnear suggested that the base spec doc should include a definition of standard data types for use in future options. Droms said he would put framework and data types for option definitions in base spec. Kinnear suggested relay agent option numbers should come from the same number space as client option numbers. There was some discussion about this suggestion but no consensus about a resolution. Issue: Should client be allowed to include requested or preferred option values in Solicit message? Solution: Yes. WG discussion: Lemon wants to allow clients to request specific options but not values for those options. Richard Jones suggested placing general prohibition on requesting specific values but allowing exceptions for individual options, to be specified in option spec. Lemon also suggested that option specs should clearly articulate what it means when a client and a server sends the option. Issue: What about DDNS-DHCP interaction? Solution: Apply current specs to DHCPv6 as well; not required for base spec Outstanding issues: Is the current spec adequate; what options are needed? WG discussion: Mark Stapp will be asked to extend current DDNS-DHCP interaction docs for DHCPv6. Issue: Is merging DHCPDECLINE function from DHCPv4 into Release message a good idea? Solution: No; define new Decline message Issue: Does a DHCPv6 server need to differentiate between Request messages sent by client when initializing, confirming and extending address lifetimes? Solution: Yes; define different messages for each situation Issue: What if there is more than one relay agent on a link and the client receives multiple responses? Solution: Make sure DHCPv4 operation is carried forward Issue: Through what mechanism should an application communicate with the server? Solution: TBD WG discussion: There was an inquiry about whether the base spec should mention and API; no action for now Issue: What authentication mechanisms need to be defined in base protocol spec? Solution: Define authentication framework like DHCPv4; define one mandatory authentication protocol (e.g., DHCPv4 HMAC/shared-secret unless we can come up with something better) WG discussion: In an IETF security briefing (previous day) Jeff Schiller said HMAC/shared-secret is good enough; check with security experts for something better. WG discussion after review of -16 rev issues: * Milestones/timeline TBD to get to last call before next WG meeting (Minneapolis); see below for final schedule * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. * Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution. * IA identification in draft is based on tuple (UUID, binding-id). WG must develop rules for generating guaranteed unique UUID and whether server should also include link prefix with IA identifier. Lemon summarized his thoughts on generating UUID and will write a draft. Lemon will also write up requirements for UUID. Narten said UUIDs are in use elsewhere and we should research those other UUIDs. Discussion on IA identification will continue on WG mailing list. New schedule: Continue discussion of outstanding issues now Rev -17 of spec 1/31/2001 Teleconference 2/12/2001 Rev -18 of spec (if necessary) or last call 2/28/2001 WG review or last call Minneapolis 3/xx/2001