DHC WG Minutes (DRAFT) for IETF-106 (Singapore) Prepared by Bernie Volz, last updated 11/26/2019 @ 15:00 EST. Date: Monday, November 18, 2019, 10:00-12:00 (Monday Morning session I) Location: VIP A Chairs: Tomek Mrugalski & Bernie Volz Presentations materials: https://datatracker.ietf.org/meeting/106/materials.html#wg-dhc YouTube video: https://www.youtube.com/watch?v=2_QREKhcfNo Executive Summary/Action Items: - draft-ietf-dhc-problem-statement-of-mredhcpv6, after title change, appears to be ready for WGLC. - draft-ietf-dhc-dhcpv6-yang needs some cleanup and review, but hopefully can also soon be ready for WGLC. - draft-fkhp-dhc-dhcpv6-pd-relay-requirements seems to have interest from the WG and after an update should have a call for adoption. - Tim Winters announced that there will be a "virtual plugfest" likely in March 2020 to test implementations of RFC8415 to facilitate meeting requirements to advance to full standard. 1. Administrativia (Agenda Bashing, WG Status, ...), Chairs - 10 minutes Tomek Mrugalski noted the note well, introduced the co-chairs, reviewed the agenda and WG document status. 2. Problem Statement of Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Lin He - 10 minutes draft-ietf-dhc-problem-statement-of-mredhcpv6 Lin He presented the slides. Suresh Krishnan (AD) stated that the draft looks more like a survey draft than a problem statement. What do you mean by problem statement? Lin responded that IP address generation is closely related to the manageability, security, privacy protection, and traceability of networks. As DHCPv6 assigns IPv6 addresses and continues to be extended and improved through new options, protocols or message processing mechanisms. We presented an overview of extensions in the draft. Bernie Volz indicated that the draft initially started out as to how to control address assignment and had morphed over the years. Suresh and Bernie suggested that the title be updated to better reflect the content. Perhaps "Survey of existing extension mechanisms" or something similar. Action: Authors to propose new title and discuss with chairs; once new title is formulated, draft will be republished (under same draft document name) and the chairs will then start a WG Last Call. 3. DHCPv6 Yang, Ian Farrer (remote) - 30 minutes draft-ietf-dhc-dhcpv6-yang Ian Farrer presented remotely (thanks to Meetecho team): - major update since IETF-104, new author (Michal Nowikowski) joined, the work is back on track - reuses IETF interfaces yang model structure - outstanding cleanups, primarily to prefix delegation - implementation specific parameters moved to an extension, listed in an appendix. Shows how to extend the general model to cover specific implementations. Uses the augment mechanism from YANG. - previous version tried to model all 140+ options. And, there was a problem with how to handle all these options (server-specific, server-only, etc). So, the team chose to trim down to model only the options in RFC8415 and explain how to augment the model. There was a brief discussion about possible follow-up draft that would codify YANG model extension for existing options once this draft is published. Suresh pointed out that the model revision is wrong (still 2018), and needs to be updated. Ian will correct in next revision. Chairs asked who would review - only one volunteer. WG will need reviewers! Suresh encouraged doing the WG to do a WGLC soon. 4. DHCPv6 Prefix Delegating Relay, Ian Farrer (remote) - 20 minutes draft-fkhp-dhc-dhcpv6-pd-relay-requirements Ian Farrer presented remotely (again, thank to Meetecho team). - 02 published very recently, informational now (was standards track). - Reviewed the issues in the draft which enumerates operational problems. Bernie pointed out that a CMTS was a "delegating relay" in DOCSIS (cable). Tim Winters stated that he thought the draft was very useful as he has seen relays doing all sorts of interesting things. And, proposed to expand the draft and title to cover general message processing (i.e., IA_NA) as well. Erik Kline asked about section 4.1, requirement G1 and how the modification related to forwarding without modifications. Bernie answered that as relay agents encapsulate messages, there is no need to modify packets. Bernie pointed out that SAVI has specified how intermediate devices (switches and routers) might track DHCPv6 assigned addresses; but SAVI did not extend to prefix delegation. Someone stated there was pushback against SAVI from vendors. Bernie also mentioned that while somewhat different, as it deals with CPEs, is the draft-gont-v6ops-cpe-slaac-renum by Fernando Gont, et al. These documents are somewhat related in that for graceful renumbering to work properly, both "delegating relays" and CPEs must be able to handle multiple IAPREFIX options in a single IA_PD. There was also a discussion about the use of RFC2119 language in an Informational draft; and usage is not the same as it is in RFC7084. It is best not use RFC2119 "language" at all in this document. 5. Advancing DHCPv6 to Full Standard, Chairs & Tim Winters - 20 minutes Tim Winters presented on what was required to bring RFC8415 to full standard and that the WG has in its charter to do this work. Tim Winters announced that the University of New Hampshire Interoperability Lab (https://www.iol.unh.edu/) is planning a Virtual Plugfest to test RFC8415. Some of the initial details are: - Likely the March 2020 Spring Break week (March 16-20). - People are generally not required to be on site, but they certainly can if they want to. - More details should be available over next 1-2 months. Someone asked if there will be announcement sent to DHC? And, Tim answered yes. Bernie asked about the timeframe for the IPv6 Ready Logo and Tim answered that he thought it would be around the May 2020 timeframe. There was a general discussion as to whether there are any unused features in RFC8415. IA_TA was raised. Tim is not aware of any usage based on his testing. Bernie indicated Windows at one time has used IA_TA; not sure if still used today. Suresh indicated that he would very much prefer to not republish RFC8415. The WG conclused the meeting about 11:10am (a bit early).