[dhcwg] Draft minutes from Atlanta

Ralph Droms <rdroms@cisco.com> Thu, 12 December 2002 12:52 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21165 for <dhcwg-archive@odin.ietf.org>; Thu, 12 Dec 2002 07:52:24 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCCspd16617 for dhcwg-archive@odin.ietf.org; Thu, 12 Dec 2002 07:54:51 -0500
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCCspv16614 for <dhcwg-web-archive@optimus.ietf.org>; Thu, 12 Dec 2002 07:54:51 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21162 for <dhcwg-web-archive@ietf.org>; Thu, 12 Dec 2002 07:51:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCCjov16367; Thu, 12 Dec 2002 07:45:50 -0500
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCCiWv16314 for <dhcwg@optimus.ietf.org>; Thu, 12 Dec 2002 07:44:32 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20999 for <dhcwg@ietf.org>; Thu, 12 Dec 2002 07:41:34 -0500 (EST)
Received: from funnel.cisco.com (localhost []) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCCiwOw001563 for <dhcwg@ietf.org>; Thu, 12 Dec 2002 07:44:59 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-660.cisco.com []) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA07762 for <dhcwg@ietf.org>; Thu, 12 Dec 2002 07:44:27 -0500 (EST)
Message-Id: <>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 12 Dec 2002 07:44:22 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [dhcwg] Draft minutes from Atlanta
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
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>

			DHC WG Meeting minutes
			 (Draft, 12/12/2002)
		      IETF 55, Atlanta, 11/2002

Administrivia, agenda bashing, Ralph Droms
CableLabs Client Configuration option draft is in IETF last call.  So
far, the last call has elicited comments requiring some editorial and
minor specification changes.

DHCPv6 specification has been reviewed by IESG, and requires small
edits to text describing relay agent security.  Droms will post
summary of changes to WG mailing list.

Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay
Agents and Servers, Ralph Droms
draft-droms-dhcp-relay-agent-ipsec-00.txt describes use of IPsec for
securing messages between relay agents and servers.  Carl Smith asked
if it is different than the mechanism in the DHCPv6 draft; answer:
no.  Narten asked for comparison with Stapp's
draft-ietf-dhc-auth-suboption-01.txt.   Droms noted IPsec mechanism is
hop-by-hop while authentication options covers entire path; IPsec
mechanism incurs extra complexity if there are multiple relay agents
in the path to the server.  The WG agreed to take the document on as
a WG document.

The Authentication Suboption for the DHCP Relay Agent Option,
Mark Stapp
draft-ietf-dhc-auth-suboption-01.txt specifies a DHCP-specific
mechanism, based on a relay agent suboption that contains a message
digest for checking message integrity.  This mechanism uses shared
keys and includes an identifier mechanism to accommodate edge devices
that don't use giaddr.  With additional changes, this mechanism can
accommodate multiple, nested relay agents.

The WG was asked what to do with the two proposals: advance both,
adopt one?  Does the WG have a clear understanding of the two
proposals?  Ted Lemon asked how we might weight the pros and cons.
Thomas Narten and Stuart Cheshie asked if there is any data on whether
IPsec implementations are available to relay agents today.  Mark Stapp
asked about potential computational complexity issues.  Stapp, Lemon
and John Schnizlein all asked what the perceived customer requirements
are.  Droms expressed concern about interoperability if both proposals
are advanced.  Erik Nordmark asked how relay agents would be
configured to use IPsec or with the keys for the relay agent option.
Droms pointed out that reuse of IPsec technology implies the
availability of future IPsec enhancements.  Schnizlein volunteered to
organize discussion of pros and cons of both proposals on the WG
mailing list.

DHCP Option for SNMP Notifications, Mark Bakke
draft-bakke-dhc-snmp-trap-01.txt was developed to address requirements
for systems using diskless boot to obtain a list of IP addresses to
which to send SNMP traps.  Narten asked which WG is best for
discussion of this option - in theory, details should be discussed in
an SNMP WG with final review of syntax and compatibility in the dhc
WG.  Narten will coordinate review of the document with MIB groups in
the IETF, and the document will ultimately be a dhc WG work item, as
there are no appropriate active SNMP WGs.  There was a question about
whether the option should be expanded with multiple sub-options for
different trap types.

Subnet Allocation using DHCP, Richard Johnson
This proposal describes a mechanism through which a DHCP server can
delegate a block of addresses (IPv4), collect usage data on the
delegated addresses and deprecate use of addresses.  It is similar to
the prefix delegation mechanism for DHCPv6.  Ted Lemon pointed out
that this proposal would require a major revision to existing
server, and he suggested that the authors review previous, related
work by Walt Lazear.  The WG agreed to take on this document as a WG
work item.

DHCP Server-ID Override Suboption, Richard Johnson
Some DHCP client messages, such as DHCPRENEW, are unicast directly to
the DHCP server and not received by a relay agent.  Thus, relay agents
are unable to add relay agent options to those messages.  This
proposal provides a mechanism through which the DHCP server can
configure the client to respond to the relay agent rather than
directly to the server.  Narten asked if continued expansion of relay
agent options is a good thing.  WG consensus is that relay agent
options have been found to provide function that cannot be provided in
other ways, and the full range of application for relay agent options
is still being explored.  Stapp suggested revisiting the relay agent
option specification, RFC3046, as a WG charter item.  The WG agreed to
take on this document as a WG work item.

Considerations for the use of the Host Name option, Carl Smith
Carl had one question for the WG: how can a client request that its
name/address association be removed from DNS?  Can we use the FQDN to
accomplish this result?  Kim Kinnear and Ted Lemon asked what customer
requires this result.  Bernie Volz suggested revisiting this question
after the DHCPv6 FQDN model is completed.

Load Balancing for DHCPv6, Bernie Volz
Any more changes needed in this draft?  No; so this document is ready
for WG last call after DHCPv6 spec has advanced.

Other DHCPv6 options, Ralph Droms
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt has folded prefix
delegation into identity associations; the document is also under
discussion in the ipv6 WG.

draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt are all ready for WG last
call as soon as DHCPv6 advances.

draft-ietf-dhc-dhcpv6-opt-dstm-01.txt and
draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt are to be synced up with
v6ops work.

Lemon, Volz and Narten all asked about the requirement for the
mechanism proposed in draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt.
A K Vijayabhaskar (author) to clarify motivation and requirements in
the specification.

A Guide to Implementing Stateless DHCPv6 Service, Ralph Droms
Droms asked the WG about the best way to specify the parts of DHCPv6
required for stateless DHCPv6 operation ("DHCPv6-lite") - for example,
for providing DNS server configuration without address assignment.
Stuart Cheshire asked if the document should be informational or
standards-track.  Another possibility would be BCP.  The WG asked that
the Reconfigure message be added to
draft-droms-dhcpv6-stateless-guide-01.txt and accepted the document as
a dhc WG work item.

Revised DHC WG charter and milestones, Ralph Droms
Droms reported that the revised charter and milestones have been
submitted to the IESG.  The IESG suggested adding a separate charter
item to develop a mechanism through which a client can authenticate a
server without authentication of the client by the server.  Droms will
add the relay agent charter item suggested by Stapp (see above).

Carl Smith, Bernie Volz and Barr Hibbs volunteered to be a design team
that will follow up on the charter item to review RFC3118; they will
develop a threat model and analysis of the authentication provided by
RFC3118.  Barr Hibbs volunteered to coordinate and act as editor for a
review of the DHCPv4 specification.

Recycling option codes, Ralph Droms
There are more than 15 options codes that have been assigned but never
used.  Droms will publish an Internet Draft identifying these option
codes and asking for feedback from the Internet community about
whether these option codes can be returned to IANA for reassignment.
After the Internet Draft has been reviewed by the dhc WG and by the
IESG, it will be submitted to IANA.

DHCP Lease Query, Kim Kinnear
The WG last call on draft-ietf-dhc-leasequery-05.txt has completed.
Based on input from the last call, Kinnear has changed the draft to
use a new option rather than overloading the requested address
option, and has made other editorial changes.  The document is now
ready for submission to the IESG.

Link Selection sub-option for the Relay Agent Information Option,
Kim Kinnear
Last call on draft-ietf-dhc-agent-subnet-selection-04.txt has
completed.  This document is waiting for authentication of relay agent
messages to be resolved.

DHCP Subscriber ID Suboption for the DHCP Relay Agent Option,
Richard Johnson
This option, in draft-johnson-dhc-subscriber-id-00.txt, is motivated
by a requirement to identify a subscriber in a relay agent option,
regardless of the port to which the subscriber is attached.  The WG
agreed to take on this document as a WG work item.

DHCP Option for Geographic Location, John Schnizlein
This option, in draft-polk-dhcp-geo-loc-option-00.txt, passes location
information about a DHCP client from the server to the client.  The
immediate purpose is to provide location information to IP phones.
The geopriv WG will own the semantics, while the dhc WG will own the
protocol and the syntax of the option.

The DHCP Client FQDN Option, Mark Stapp
DDNS-DHCP conflict resolution, Mark Stapp

Stapp reported on draft-ietf-dhc-fqdn-option-05.txt,
draft-ietf-dnsext-dhcid-rr-05.txt.  There are no deployed
implementations of these drafts.  Cisco and two others have
(non-interoperable) implementation that use TXT RRs, waiting for
approval of DHCID RR.  Droms asked for a summary of changes to the
current drafts.  Stapp will post summaries to WG mailing list.
Gudmundsson asked if the DHSID RR should become a more general RR
type.  WG consensus was no, as that would delay progress of these
drafts and there is no specific requirement for other, similar RR
types.  Gudmundsson and Droms agreed documents are ready for dnsext
and dhc WG last call.

dhcwg mailing list