[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@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg