[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dhcwg] IETF-67 dhc WG meeting minutes
Here are draft minutes from the IETF-67 dhc WG meeting. Note that they must
be sbumitted by tomorrow, 12/8, so respond with additions, corrections or
comments as quickly as possible. I apologize for the short notice...
- Ralph
=====
These minutes are based on notes taken by John Schnizlein and the
jabber log from jabber scribe Andre Kostur.
The chairs opened the meeting with the usual administrivia. First
topic was review of WG drafts that are ready for WG last call and WG
adoption.
WG last call:
draft-ietf-dhc-dhcpv6-agentopt-delegate-01
draft-volz-dhc-dhcpv6-srsn-option-00
These two drafts will be submitted as a package to IESG.
draft-volz-dhc-dhcpv6-srsn-option-00 was accepted as a WG work item
on Oct 27. Note that draft-volz-dhc-dhcpv6-srsn-option-00 was
discussed in a little more detail later in the WG meeting. The
consensus in the room was that the documents are ready to go to WG
last call; the consensus will be confirmed on the WG mailing list
after draft-volz-dhc-dhcpv6-srsn-option-00 is republished as dhc WG
work item draft-ietf-dhc-dhcpv6-srsn-option-00 and
draft-ietf-dhc-dhcpv6-agentopt-delegate-01 is revised with some
editorial changes based on draft-volz-dhc-dhcpv6-srsn-option-00.
draft-ietf-dhc-dhcpv6-reconfigure-rebind-00
This document text in 3315 about where client sends its DHCP
message in response to receipt of a Reconfigure message, and that
Reconfigure message can cause client to send a Rebind message as
well as a Renew message. The update will be written as a new RFC
updating RFC 3315 rather than as an errata. The consensus in the
room was that the document is ready to go to WG last call; the
consensus will be confirmed on the WG mailing list
draft-ietf-dhc-subnet-alloc-04
The consensus in the room was that the document is ready to go to WG
last call; the consensus will be confirmed on the WG mailing list.
There was a concern raised about the IPR statement published to the
IETF related to this document: how can DHCPv6 prefix delegation not
have an IPR statement while this document does? Fred Templin
(Boeing) want to use draft-ietf-dhc-subnet-alloc-04 and wants
assurance about lack of encumbrance. The concerns will be addressed
during the WG last call.
draft-ietf-dhc-dhcpv6-ero-00
This document was recently accepted as a WG work item through the WG
mailing list. The document provides a way for a relay agent to
request which options it wants to see in the relay-reply. The new
agent is much like the client Option Request option, but for relays.
The consensus in the room was that the document is ready to go to WG
last call; consensus will be confirmed on the WG mailing list
Other WG business and activities:
draft-ietf-dhc-failover-12.txt
After a long period of inactivity, renewed interest in progressing
the document has been expressed from 3 independent sources. The
interested parties are to meet after the WG meeting to form an ad hoc
design team that will develop an action plan.
WG rechartering
The chairs have updated the WG charter. There were no objections to
the revised charter during a brief review in WG meeting. The WG
will discuss revised charter on the WG mailing list.
Presentations and WG document reviews:
draft-daniel-dhc-mihis-opt-02
Daniel Soohong Park presented a summary of this document, which
defines a DHCP option to provide the DHCP client with the address of
an IEEE 802.21 Information Server. The Information Server is used
for handoffs. The need for this option needs to be confirmed with
the IEEE 802.21 working group and the requirements for the option
itself should be developed in the IETF WG working on IEEE 802.21.
draft-ietf-dhc-dhcvp6-leasequery-00
Bernie Volz presented a summary of the revisions to this document
made since the previous dhc WG meeting. The protocol has been
significantly simplified in response to comments received at the
last WG meeting: by-address is now the only query type; bulk
transfer has been removed. David Hankins said that this revision
more than meets his concerns. Alain Durand agreed that there the
document was ready for progress, and suggested that the WG consider
other transports like XML. John Brzozowski said that Comcast is
still interested in pursuing the bulk transfer mechanism. The
consensus in the room was that the document is ready go to WG last
call; consensus will be confirmed on the WG mailing list.
draft-stenberg-pd-route-maintenance-00
This draft, as explained by Markus Stenberg, addresses the problem
of injecting route information into the routing infrastructure in
conjunction with prefix delegation (DHCP PD). Alain Durand and
David Hankins noted that the draft is a comprehensive review of all
possible solutions and that some of the proposed solutions are not
practical. The chairs asked if the document might fall under the
charter of the v6ops WG. Jari Arkko agreed that this is an
informational document and it seem like a v6ops WORK ITEM. The
draft will be discussed further on the WG mailing list.
draft-volz-dhc-dhcpv6-srsn-option-00
The option defined in this draft, as presented by Bernie Volz,
addresses a message sequencing issue related to
draft-ietf-dhc-dhcpv6-agentopt-delegate-01, which was first pointed
out by Thomas Narten. The consensus in the room was that the
document is ready to go to WG last call; consensus will be confirmed
on WG mailing list. Note that this draft will go to WG last call
with draft-ietf-dhc-dhcpv6-agentopt-delegate-01 (as noted above).
draft-templin-autoconf-netlmm-dhcp-04
Fred Templin gave an informational presentation about this draft; it
is not considered for dhc WG adoption at this time. The document is
under consideration as an alternative in the netlmm WG. Jari Arkko
noted that there is an ongoing discussion about address assignment
in the netlmm WG; this document presents a new, third, alternative.
Fred reported that there are two independent implementations of the
-03 revision of this draft. No dhc WG action was required at this
time; dhc WG members were encouraged to attend the netlmm WG
meeting.
draft-ietf-dhc-pxelinux-00
David Hankins gave an update and summary of the options defined in
this draft. In particular, deprecation of option 208 is a big
change. The consensus in the room was that the document is ready go
to WG last call for Informational RFC; consensus will be confirmed
on the WG mailing list.
draft-dhankins-atomic-dhcp-00
David Hankins gave the presentation about this draft, which
describes some of the details of option processing in the ISC DHCP
server. Kim Kinnear liked the advice in the document about how to
design a DHCP option, while the information about the implementation
was interesting but less useful. Ralph Droms suggested the
implementation details might be left in the draft while it is in
review, but then be removed before publication as an RFC. The
consensus in the room was that the dhc WG should take on this draft
as a WG work item (Informational RFC); consensus will be confirmed
on the WG mailing list.
draft-joshi-dhcp-lease-query-ext-02
This document, as described by Pravan Kurapati, extends DHCP
leasequery for use by L2 devices whose leasequery requests may pass
through other relay agents. Ric Pruss asked about the use of BFD to
maintain connection state with the DHCP server. Ralph Droms asked
if this problem is being addressed by the DSL Forum. Bernie Volz
asked if a solution like DHCPv6 relay agent message chaining would
be a better solution. There was no consensus to adopt this draft as
a WG work item at this time.
draft-decnodder-dhc-rai-unicast-01
Pravan Kurapati also gave the presentation about this document,
which defines an option that an L2 relay agent can use to avoid
flooding if the L2 network element does MAC address translation.
The chairs asked about the source of requirements for this new
option. There was no consensus to adopt this draft as a dhc WG work
item at this time.
draft-sarikaya-dhc-proxyagent-00
Kuntal Chowdhury gave a presentation explaining this draft, which
defines a "DHCP proxy" as a DHCP server that does not do its own
address management. Two use cases were described:
1. The DHCP proxy is co-located with gateway in WiMAX; in this
case, the gateway uses PMIP to get an address for the client
from the Home Agent
2. The DHCP proxy gets the IP address for the client from (RADIUS)
AAA server
Bernie Volz asked what was needed from the dhc WG, because this
option makes no changes to the protocol as defined in RFC 213[12].
Ralph Droms noted that, had RFC 213[12] been written only in terms
of the protocol, this draft would not be necessary. Marcus Stenberg
said that, from the specification of the protocol, the server
implementation doesn't matter. Jari Arkko raised a concern about
using NetLMM as a use case because the NetLMM documents don't
mention DHCP proxy. Ralph Droms said that he has heard the term
"DHCP proxy" but suspects it has different meanings in different
contexts; the term should be defined in other specifications where
it is used. There was no consensus to adopt this draft as WG work
item at this time.
draft-fujisaki-dhc-addr-select-opt-02
This document was presented by Arifumi Matsumoto. It defines an
option for carrying address selection rules, as defined in RFC 3484,
to a host. The WG expressed consensus to wait for work on the
address selection issue in v6ops to complete before taking on the
design of this option in the dhc WG.
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg