[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