***DRAFT*** DHC WG minutes DHC WG @ IETF-95 Etherpad Notes 1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...) - 5 minutes 2. Manufacturer Usage Description Option, Eliot Lear - 15 minutes, started at 14:08 draft-lear-mud-framework draft-lear-ietf-dhc-mud-option Suresh: whether you're progressing the MUD framework Tomek: so it's not only a simple retrieving info for the server Bernie: server might need some out of band communication Ted Lemon: it sounds no active WG for this work Suresh: it's not a simple solution Tim Chown: in OPSSEC, Stefan Winter presented a YANG model on configuring device security settings, looks like some overlap with what you do Discussion whether this is in scope for the WG. The option is sent by the client, the server is supposed to send the content to MUD server and send back to the client. This is more than a typical new basic configuration option, so it somewhat falls into "protocol extension" category, but just barely. Many server implementations support external callouts or allow exporting the data. Chairs will ask on the ML whether there's interest in this work. AD (Suresh) to follow up where in the IETF this work should be done. 3. Secure DHCPv6, Ted Lemon (for Lishan Li) - 20 minutes, started at 14:21 draft-ietf-dhc-sedhcpv6 Ted describes the update since Yokohama. Bernie asked whether there were any expert security reviewers, other than Randy Bush. Ted and Suresh talked and it seems that asking Stephen Farrell is the best next step here. Ted acknowledged that some additional work is needed and extra revision will be published. draft-li-dhc-secure-dhcpv6-deployment, started at 14:32. Suresh: this is 3 pages long, why is it even a separate draft? Bernie: there was some discussion with Lishan and it seems to be at the fence, maybe it'll stay separate or maybe will be merged. Ted: different opinion. Deployment consideration should be a separated document, so that the definition document is dedicated into technical aspects. Another option may be further expanding it to become a deployment guide and perhaps moved to OPSEC. Suresh: The DoS attack text is something that certainly needs to go in the protocol document. 4. DHCPv6 Failover Update, Bernie Volz (for Kim Kinnear) - 10 minutes, started at 14:46 draft-ietf-dhc-dhcpv6-failover-protocol Document should be ready for WGLC, but needs careful technical review. Bernie asked for volunteers for one more thorough review, sadly no volunteers 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - 10 minutes, 14:50 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue The authors believe work is ready for WGLC. Ian: Is this now informational? "This is the suggested way to do it"? Bernie: Correct. There were some discussions and the conclusion was to not enforce it. Marcin (on jabber): I'd suggest this is standards track doc with normative language in. Otherwise implementations will ignore hints. 6. DHCP Relay / Server Communication and Pervasive Monitoring, Chairs - 10 minutes, started at 14:55 Bernie explains the rationale and when the problem was raised. This was initiated because of an IESG Discuss on draft-ietf-dhc-access-network-identifier that relay to relay/server communication is not "secured" against pervasive monitoring. Tim: not only regard with security, but also what you would use the identifier Francis: The standard approach is to use IPSec. What is the problem here? Suresh: we need to consider something that Francis said earlier: there may be relays without addresses (e.g. LDRA) Tim: there are some comments from Stephen, will send them to the mailing list. Sheng: agree with there is work to be done, but if you assemble a design team, ask for a security expert first. This needs to be taken to the list to determine whether the WG believes there is a problem here. 7. DHCPv6bis update & issues discussion, dhcpv6bis team - 15 minutes, draft-ietf-dhc-rfc3315bis The plan is to submit an 05 draft in May and initiate WGLC. Volunteers were found to review the document during WGLC. Ian: for implementors, is there any digest of the difference between RFC3315 Marcin Siodeski (via Jabber): Shawn Routhier has volunteered to review Marcin clarifying my point on jabber: The RFC3315bis document includes an appendix which lists all changes we have made to the original document. It is probably easier for the reviewer to start review from reading the whole appendix as opposed to viewing all tickets we have in Trac or diffs between specific document versions. The appendix is at the end so it is easy to miss it. Volunteers for review: Ted Lemon, Bernie Volz, Mohammed Boucadair, Tim Winters, Tim Chown, Francis Dupont, Paul Ebersman Co-authors (who are supposed to review without explicitly voluneering): Bernie Volz, Sheng Jiang, Marcin Siodelski, Ian - I also volunteered to review 8. Forcerenew Reconfiguration Extensions for DHCPv4, Luyuan Fang - 10 minutes draft-fang-dhc-dhcpv4-forcerenew-extensions While the document got a good reception, it isn't clear if there is sufficient interest to adopt this work; will be taken to list.