[dhcwg] *DRAFT* minutes from dhc WG meeting in DC
Ralph Droms <rdroms@cisco.com> Fri, 03 December 2004 08:35 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12060 for <dhcwg-web-archive@ietf.org>; Fri, 3 Dec 2004 03:35:20 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca907-0005oD-Gc for dhcwg-web-archive@ietf.org; Fri, 03 Dec 2004 03:41:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca7On-0006pF-8v; Fri, 03 Dec 2004 01:58:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca60A-0000QP-HV for dhcwg@megatron.ietf.org; Fri, 03 Dec 2004 00:29:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12448 for <dhcwg@ietf.org>; Fri, 3 Dec 2004 00:29:03 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca65q-0001xu-0D for dhcwg@ietf.org; Fri, 03 Dec 2004 00:34:58 -0500
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 Dec 2004 00:37:19 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB35SVqR014305 for <dhcwg@ietf.org>; Fri, 3 Dec 2004 00:28:31 -0500 (EST)
Received: from rdroms-w2k01.cisco.com (sjc-vpn1-1387.cisco.com [10.21.101.107]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANL06972; Fri, 3 Dec 2004 00:28:28 -0500 (EST)
Message-Id: <4.3.2.7.2.20041203002517.02039a98@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 03 Dec 2004 00:28:25 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Subject: [dhcwg] *DRAFT* minutes from dhc WG meeting in DC
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Here are the draft minutes of the dhc WG meeting in DC. Please review and respond with comments by 1700 EST, Mon 2004-12-06 - Ralph Droms ----- Administrivia Ralph Droms Droms asked about interest in DHCP server MIB, draft-ietf-dhc-server-mib. The specification has been reviewed by the IESG and is close to being done. However, one author is not interested in continuing to work on the specification and the other wants to confirm that there is sufficient interest before committing to more work on the document. Ted Lemon expressed interest in seeing a server MIB (although not necessarily this one). Droms will work with Glen Waters (document co-author) to complete the specification. Reclassifying DHCPv4 Options Bernie Volz draft-ietf-dhc-reclassify-options is about to be published as an RFC. Volz described the process for broadcasting notification of the process specified in the document, and asked for assistance in identifying all vendors whose use of option codes will be affected by this specification. DNS zone suffix option for DHCPv6 Renxiang Yan draft-yan-dhc-dhcpv6-opt-dnszone Yan gave a presentation about draft-yan-dhc-dhcpv6-opt-dnszone. The key idea is to send the DNS domain from which a host should form its FQDN to the host. Ted Lemon noted that the mechanism in this specification supposes that the host will then use DDNS to update its DNS information. This use of DDNS will require management of authorization information for individual hosts, which won't scale. The RA-based mechanism in draft-jeong-ipv6-ra-dns-autoconf has similar issues of scale. Further discussion will take place on the WG mailing list before coming to a decision about taking this draft on as a WG work item. Vendor-Specific Information Suboption Mark Stapp draft-stapp-dhc-vendor-suboption There was consensus in the room to take this draft to WG last call. Droms will confirm consensus on the WG mailing list. DHCP Authentication via EAP Mark Stapp Stapp presented summary of idea to use EAP for DHCP authentication (no document, yet). The premise of this work is that requiring the use of another set of keys around just to do DHCP is a non-starter and DNSSEC is not ready, so Stapp suggests using credentials already provisioned for 802.1x for DHCP authentication. There was some discussion about where in the authentication system (AAA server?) session keys might be generated. Stapp will write a draft based on his ideas for WG review. Information Refresh Time Option for DHCPv6 Stig Venaas draft-ietf-dhc-lifetime Venaas gave an update about the draft, which has been previously discussed by the WG. The title of the specification has been changed to "Information Refresh Time Option for DHCPv6" as the option controls when a client contacts the DHCP server, but does not cause previously obtained information to expire in any way. Some minor issues were raised about max and min values for lifetime which will be discussed on WG mailing list. Pending that discussion, there was consensus in room to go to WG last call. Consensus to be confirmed on WG mailing list. Multicast Reconfig. Protocol for Stateless DHCPv6 Daniel Park draft-vijay-dhc-dhcpv6-mcast-reconf Park gave a summary of the draft. Droms asked why the protocol uses Relay-reply message to notify router (through relay) to toggle 'M'/'O' bits; isn't CLI sufficient? Greg Daley suggested SNMP might be appropriate to cause router to toggle 'M'/'O' bits. Some additional discussion about whether this mechanism is needed if "Information Refresh Time Option for DHCPv6" is accepted for standards track. Volz pointed out that "multicast reconfig" is useful for unplanned renumbering. Park was requested to provide more detail; further discussion will take place on the WG mailing list before coming to a decision about taking this draft on as a WG work item. Anycast Address Assignment using DHCPv6 Syam Madanapalli draft-madanapalli-dhcpv6-anycast Madanapalli presented summary of the draft. Ted Lemon pointed out that the slides were somewhat different from the text in "draft-madanapalli-dhcpv6-anycast", and that the second part of the specification (in which the services are classified) begins to look a lot like SLP. Droms suggested the draft might be spit into two pieces: one for assignment and one for service classification. There was consensus in the room to accept the draft as a WG work item; the consensus will be confirmed on WG mailing list. Source Address Selection Policy option for DHCPv6 T. Fujisaki draft-hirotaka-dhc-source-address-selection-opt This draft provides a protocol for distribution of address selection policy, where those policies are described in RFC 3484. The draft is related to other drafts about distribution of policy currently before the ipv6 and multi6 WGs. John Schnizlein asked if this draft is really solving a routing problem. Ted Lemon asked if this is for reasonably stable and static multi-homed networks' authors agreed that this is for source address selection policy, not routing information. Further discussion will take place on the WG mailing list before coming to a decision about taking this draft on as a WG work item. DHCPv6 Relay Agent Information Option Wing Cheong Lau draft-droms-dhc-v6-relayopt The consensus in the room was to accept the draft as a WG work item; consensus will be confirmed on WG mailing list. Clarifications on DHCPv6 Authentication T. Jinmei draft-ietf-dhc-dhcpv6-clarify-auth Jinmei-san presented a list of changes to the draft in the most recent revision and a couple of outstanding issues: * draft recommends treating multiple exchanges as a single "session", which requires additional state in the server * should this draft be published independently or rolled into a revision of RFC 3315? Jinmei-san will initiate discussion of a couple of outstanding issues and then the draft will be ready for WG last call. DHCP Relay Agent Opt for MIPv6 bootstrapping Kuntal Chowdhury draft-chowdhury-dhc-mip6-agentop J. Bharatia presented a summary of the draft, which provides a mechanism through which a remote AAA server can pass the address of a MIP6 home agent to a roaming MIP6 host for initial configuration/bootstrapping. Mark Stapp objected to the relay agent modifying the DHCP message rather than inserting information in the relay option wrapper. It was mentioned that a similar draft that accomplishes the same objective without DHCP is under consideration in the mip6 WG. The author was requested to revise the draft to avoid modification of the DHCP message by the relay and the WG will consider the revised draft. DHCP-DNS interaction Bernie Volz draft-ietf-dhc-dhcpv6-fqdn draft-ietf-dhc-fqdn-option draft-ietf-dhc-ddns-resolution Volz presented a status report: these drafts along with draft-ietf-dhc-3315id-for-v4 and draft-ietf-dnsext-dhcid-rr will go to the IESG as a package. draft-ietf-dnsext-dhcid-rr is through WG last call (dnsext). The consensus in the room was to go to WG last call on draft-ietf-dhc-fqdn-option; consensus will be confirmed on the WG mailing list. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg