These minutes are based on notes taken by John Schnizlein and the jabber log from jabber scribe Markus Stenberg. 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 -02revision 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.