Minutes for DHC at IETF-95
|Meeting Minutes||Dynamic Host Configuration (dhc) WG|
|Title||Minutes for DHC at IETF-95|
|Other versions||plain text|
***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
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
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
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
4. DHCPv6 Failover Update, Bernie Volz (for Kim Kinnear) - 10 minutes, started at 14:46
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
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
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
7. DHCPv6bis update & issues discussion, dhcpv6bis team - 15 minutes,
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
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.