Agenda:

1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...) - 10 minutes
RFC7341(DHCPv4-over-HDCPv6 Transport) published recently.
draft-donley-dhc-cer-id-option should move to Homenet
Ole: 6man tomorrow will present 3 related drafts
WG recharter completed. Call for reviews for milstone drafts.

2. Tomek Mrugalski, DHCPv6bis Update (draft-dhcwg-dhc-rfc3315bis) - 15 minutes
In progress, but still many open issues, particularly, incorporating stateful-issues
DHCPv6bis meeting on Monday, shorter milestones, first monthly meeting, Dec 10th
Call for review for this document.
Need one single editor to make the texts consistent (Bernie may take the role).
 
Discussion on Client rate limiting (#119)
Initial proposal: 60 messages in 60 seconds, default values, may to tweak it
Ian Farrer: concern about large amount of clients (thousands), What¨s the follow-up
Christian Huitema: On the server side, it is an implementation issue. 
Daniel: not sure initiate transmissions
Bernie: some RFC did similar rate limiting, might need to look at RFC regarding to ICMP traffic.
Tomek: It is the default value. For cable model, maybe it needs lower.
Q1: Do we need configuration options like SOL_MAX_RT?
Ted: I think we don't.
Limit is enforced per link for multiple interface devices.

Discussion on Deprecate IA_TA (#124)
Deprecate means: existing implementations/deployments may use it, new implementations should skip
Ole: lots of work been doing on privacy. 
Tomek: two things clarified: deprecate the IA; clients accept the always changing addresses
Ted: don't think it simplified the client lifecycle; should
Christian Huitema: a lot of implementations relay on the association
David Lamparter: less improvement in privacy
Sheng Jiang: don't like this proposal on Monday dhcpv6bis team meeting. Just deprecating it might cause other new issues. Although there are issues with IA_TA, WG should work on them.
Ted Lemon: put some text in the section like "for server won't give you TAs, this what you can do"
The rough consensus (1 or 2 comments in favor, many against deprecating) in the room was that IA_TA should not be deprecated.
Bernie: next meeting, dhcpv6bis team meeting will be arranged in the second half of DHC WG meeting to allow more people participate
Sheng Jiang: should adopt this draft before the next meeting if we want to process it
Ted Lemon: encourage to adopt the draft

3. Suresh Krishnan, DHCP privacy considerations - 20 minutes
    Drafts: draft-jiang-dhc-dhcp-privacy and draft-krishnan-dhc-dhcpv6-privacy
Proposal of privacy mitigation is not included. They need to be separated document. Next step will also include server side privacy.
Sheng Jiang: IA_TA is the major different between DHCPv4 and DHCPv6
Bernie: client-relay actions or relay-server actions is also relevant, but may need less protection
Discussion on attack use cases
Christian Huitema: one possible attack. Proposal of privacy mitigation is not included
Andrew Yourtchenko: DUID will be normally encrypted, MAC address is open
Lorenzo: which thread is stateful and which is stateless. For stateless, most of these threats go away.
Lishan Li: IETF should consider more on privacy, what protocol should consider privacy?
Suresh: IAB has a privacy document, it's a common consideration. Almost every protocol is relevant to privacy.
Daniel: basically privacy is everywhere
Lorenzo: unless some anti-privacy work. Some protocol may be anti-privacy on purpose. Some information provided by DHC servers is anti-privacy. 
Christian: it also depends on software and IOS version. Legacy software is always problem.
Ted lemon: thread model, what need to be encrypted
Suresh: will add use cases.
Lorenzo Colitti: although DHC is bootstrap protocol, should not add too many configurations. Two goals conflict to each other.
Suresh: in RFC new DHCP option guidance has text for anti-privacy
Ted: int directory should do the work.
Lorenzo Colitti: infrastructure problem, if the information is needed by user, then privacy could be problematic. 
Tomek: will adopt the privacy problem analysis drafts soon. And will need mitigation draft.
Marcin Siodelski: the draft to be informational or standard track?
Suresh: informational
Tomek: mitigation draft might be info or BCP, but will decide later
 
4. Marcin Siodelski and Bernie Volz - draft-ietf-dhc-dhcpv6-stateful-issues - 15 minutes
Ian: 3633 doesn't specify the behavior, if relays repeat and repeat Renew/Rebind
Bernie: have a ticket in 3315bis, but not really deal with it
Presenting updates in -07 and -08.
Tim Winters: Is there a text what clients do with T1=T2=0? If clients choose a value, it should choose the same for all IAs.
Ted: what is the actual semantic meaning of T1=T2=0, in what situation it make sense?
Ted: the original question is the client should renew before the shortest expires
Tim Winters: I have 2 major implementations that send them as 0s. You'll have major interoperation problems if clients start rejecting them.
Ted: we wrote this kind of implementation
Bernie: 3315bis should clarify this issue
Ted: We may disallow the servers to send it and let clients to process it.
Andrew: relaying a comment from jabber from Qi Sun: does the draft covers also any other future IAs?
Marcin: No, we explicitly limited the draft to IA_NA and IA_PD only.
Bernie: It doesn't make sense to cover any future IAs as we don't know what their use cases and lifecycle would be.
Marcin: Thanks to the reviewers that volunteered during IETF90. Unfortunately only 2 out of 8 reviewed.
Still pending reviews from Leaf Yeh, Francis Dupont, Jason Weil, Ian Farrer, Qi Sun, Cong Liu.
Asking for additional reviewers: Suresh Krishnan, Ted Lemon, Tim Winters and Tomek Mrugalski signed up.

5. Lishan Li - draft-cui-dhc-dhcp4o6-active-leasequery - 15 min
Bernie: DHCP in IPv6 tunnel draft is in softwires Working Group.
Marcin: bulk leasequery requires leasequery to be implemented
Ian: whether source address option carried in v4 option. We will send the option draft to dhc WG for review.
Note: The related option discussed is defined in draft-fsc-softwire-dhcp4o6-saddr-opt.
Bernie: we need to review it along with the 4o6 leasequery draft and will see what the next steps are.
 
6. Fred L. Templin - draft-templin-aerolink - 15 minutes
Bernie: this presentation is purely informational for DHC, DHC won't do the work.
Fred: we have an unsolved issue: 	how the server know client is authorized to use its claimed Client ID (DUID) 
Sheng Jiang: confused by the requirement. This may have to request that dhcp server statefully assign and manage the client DUID. The DUID is generated by client, why it should be authorized by the server.
Fred: requirement is server need to authorize the client
Christian: if you need this, just restore clients' certificates in the server.
Sheng: this is also supported in secure DHCPv6
Fred: that should solve out requirements