John: administrivia
I-D status review
  Draft-ietf-subnet-alloc to be submitted to IESG.
  draft-ietf-dhc-dhcpv6-reconfigure-rebind to be re-published and
  submitted to IESG.  draft-ietf-dhc-dhcpv6-relay-supplied-options has
  passed WG last call.  Draft-ietf-dhc-options-guidelines and
  draft-ietf-dhc-dhcpoption-clarify are both active; chairs need a
  status update from David Hankins.

draft-jiang-dhc-cga-config-dhcpv6, Sheng Jiang
  WG work item?  Ted Lemon (Ted): Why is it right for the server to
  tell the client what sec value to use?  Sheng Jiang: Network admin
  might want clients to use higher vlaue than default.  Ted: does sec
  value vary between networks?  Sheng: Yes; sec value has large impact
  on computation required. Jean-Michel Coombs: Why has CGA delegation
  been removed?  Ted: It's an unusual thing for a DHCP server to do
  and will be done later in separate draft to isolate controversy.
  Ted: Seems we can expect new clients to have higher value as
  default.  Sheng: Always OK for client to have higher value.  But, if
  network says "sec must be > 1" to get network access, client needs
  to know that sec value.  Ted: So sec is floor value.  Sheng: Not
  exactly, host has freedom to use lower value but risks not getting
  network access.  Ted: Value or confusion?  Asking computer to make
  value judgment; how does client decide to honor sec value.
  Jean-Michel: same problem as if server provides DNS server; client
  can choose another server.  Ted: Client can be attacked with either
  a low value or a high value of sec.  So, can server provide useful
  config through sec value?  Sheng: Suppose secure DHCP.  Ted: But we
  don't really have secure DHCP.  Sheng: Server communication
  protected through CGA.  Shree Joshi: Suppose client generates
  address and sends to server?
  Conclusion: 6-7 interested (50% of room); 8 "good idea"; 0 "bad
  idea"; WG work item on mailing list

draft-yeh-dhc-dhcpv6-prefix-pool-opt, Leaf Yeh
  (picking up in the middle of the conversation) Shree: How is it done
  today?  Why not a routing protocol? John: It would be configured
  manually.  Ted: original model might have been for the PE to get a
  /40 and then have a dhcpv6 server; using this architecture as a
  model, build a message exchange that looks the same except retain
  authority for delegation.  Leaf: Simplified PD, new message exchange
  from PE, would solve the use case.  Ted: Server can send reconfigure
  when it notices no leases are left through the prefix on the PE.
  Conclusion: continue discussion on mailing list

  [Added by Ted later]: Summarizing the technical part of the
  discussion, what we talked about was turning this into something
  very much like prefix delegation.   The difference is that with
  prefix delegation, the DHCP server delegates the work of address
  allocation for a prefix to the DHCP server receiving the delegation.
  In this extension, the DHCP server allocates a prefix to a particular
  router just as with prefix delegation, but the router still forwards
  DHCP messages through to the DHCP server, rather than allocating
  addresses itself.   We didn't discuss the details of how this would
  work, but this is the basic idea.

draft-ietf-dhc-vpn-option-12.txt
  No discussion
  Conclusion: chairs will start new WG last call

draft-ietf-dhc-dhcpv4-bulk-leasequery-03.txt
  Ted: was through WG last call with sufficient support; if authors
  think they are ready, should go ahead.  No objection in the room
  Conclusion: chairs will start new WG last call

draft-kinnear-dhc-dhcpv4-active-leasequery-01.txt
  Ted: Big question is that this mechanism pretty much replicates
  failover.  Anyone in the room interested: 2; how many want to adopt:
  1.  No quorum in the room.
  Conclusion: discuss acceptance as WG work item on mailing list

draft-mrugalski-remote-dhcpv6
  Jean-Michel: Mobile node will be able to get new care-of address
  before leaving home address?  Tomasz: yes, and can get some other
  configuration from home after moving.  Jean-Michel: what about DAD
  for new address on old network?  Tomasz: am writing a draft to solve
  that problem.  Ted: is there a customer for this idea?  John: could
  it reside on experimental until a customer emerges?  Ralph: Add
  specific warnings to abstract prior to publication as Experimental
  RFC.  Ted: develop consensus for interest on mailing list
  Conclusion: no formal WG action at this time

draft-madi-dhc-dhcpv6-psac
  Ted: Client-supplied public key to encode response?  How is key
  known to be valid?  Ma Di: not used for identification.  Ted: does
  each client get a separate SA key?  Di: secret is bound to DUID;
  server manages binding.  Ted: where is SA key from?  Di: generated
  by server; secret on;y to client.  Ted: how does client know it's
  talking to a valid DHCP server?  Di: pre-shared key implies ID of
  server  Ted: will only work on enterprise network with, e.g., WPA2
  confidentiality.  Di: not appropriate for public wireless Ted: needs
  more text in security considerations about where this mechanism is
  useful
  Conclusion: Continue discussino about acceptance as WG work item on
  mailing list

draft-ietf-dhc-dhcpv4-relay-encapsulation
  (prior to presentation) Ted: China Mobile has done an
  implementation and will give presentation.  Then Ted will give high
  level description.
  --presentation--
  No discussion.
  Conclusion: additional discussion on WG mailing list

draft-jjmb-dhc-dhcpv6-redundancy-considerations
  No discussion
  Conclusion: document is in-charter for dhc WG; John, et al., will
  write personal I-D for WG review

draft-ietf-dhc-pd-exclude
  No discussion
  Conclusion: will continue discussion on WG mailing list