The DHC working group met twice in Oslo. The first meeting was used for discussion of DHCPv4 issues. Thanks to Stuart Cheshire for taking notes for these minutes. Here is a summary of discussion items and resolutions: DHCP authentication, Droms (for Arbaugh): Droms reviewed most recent draft. WG asked for revision: describe authentication for DHCPRELEASE, develop PKI example (Olafur Gudmundsson?), other minor fixes (to be submitted by WG). After revision is submitted, new draft will be submitted for WG last call. DHCP authentication, Gupta: reviewed recent draft proposing "protocol 2" for Droms/Arbaugh authentication. Gupta proposal is a generalization of the Droms/Arbaugh mechanism that supports public keys and roaming; new features include: Support for PK authentication Replay counter field replaced with replay-detection field MAC field replaced with authenticator field which may contain PK signatures as well as shared-key MAC In response to question about merging Droms/Arbaugh and Gupta protocols, WG consensus is to leave as two separate protocols. Droms/Arbaugh will review Gupta proposal to determine if modifications to packet format are warranted to accommodate Gupta "replay detection method" field. Name service search order, Smith: reviewed recent draft proposing new option for specifying name service search order; e.g., NIS+, NIS, DNS. WG reacted favorably and asked for final draft that will be submitted for WG last call. DHCP-DNS interaction, Stapp: reviewed changes in recent draft: added optional use of DNS encoding for FQDN, clarified administrators' options in deployment, tightened and clarified language, revise key RR protocol. Narten raised issue of obtaining key RR number; he and Stapp will obtain number and then go to last call within a month. DHCP failover protocol, Volz: reveiwed changes in most recent draft; most significant is exclusive use of TCP. Kinnear will schedule teleconferences for: TCP, load balancing, security over next month to finish draft before Washington IETF. LDAP schema for DHCP, Volz: reported on most recent revision to LDAP schema draft. Volz noted that the schema has several shortcomings that a policy-oriented schema might eliminate. Yet, a policy-oriented schema would be rather difficult to map to current servers. He sees three alternatives for moving forward: 1) continue with current direction; 2) move to more policy-based model; 3) scale back to record only lease information and not configuration information. Discussion to continue on mailing list. DHCP over IEEE 1394, Fujisawa: reviewed recent draft. Fujisawa explained key architectural issue that affects use of DHCP: node IDs can change at any time; e.g., whenever new device is plugged into bus. Thus, node ID cannot be used for client's hardware address and for client identification. WG discussed use of EUI-64, UUID as client identifier and client hardware address for DHCP. Issues will be taken to mailing list for further discussion. Futures panel, Droms (for Carney): reviewed recent draft report from futures panel. No comment from WG; will report to Carney and determine if draft needs further revision before WG last call. WG administrative details, Droms: WG agreed to collapse all DHCP mailing lists into two lists: dhcp-v4 and dhcp-v6 No support for user class option; will confirm with message to mailing list and then remove from WG charter Bill Sommerfield agreed take over server selection option Mark Stapp agreed to complete option code recovery process The second WG meeting was used for discussion of recent developments in DHCPv6 process: Mike Carney has agreed to become an author of the documents. He will have control of the documents' sources. Mike, Jim and Charlie plan to have a revision to the documents complete by the Washington IETF. The WG agreed on the following plan for completion of the documents: Develop list of issues to resolve; obtain WG consensus that list is as complete and appropriate as possible Develop solutions to issues from list; obtain WG consensus that solutions are correct Revise document based on solutions Obtain WG consensus that solutions are captured in revisions to specification Revise document for WG last call WG last call The WG developed an expanded list of goals and delivery target dates; List of issues: 8/15/99 Solutions to issues: 10/ 1/99 Revised draft: 11/10/99 (Washington IETF) Consensus on solutions Revised draft: 3/ 1/00 (Australia IETF) WG last call The WG developed the following list of issue areas and developed issues in each area. The areas are: Current technical issues Undiscussed issues from Minnesota WG meeting Unresolved issues from WG last call Releasing resources: too many alternatives? (Section 6) Is the mandate for implementation strategy too strong? Why is XID transaction cache described in such detail? Which messages are not idempotent (and why not)? How does a client request addresses from multiple prefixes? Does the RECONFIGURE mechanism scale w.r.t ACK implosion? New RECONFIGURE reduces messages from 2N to N, but N may still be large. In case of a RECONFIGURE failure, loosen text to specify "notify administrator" (rather than "log to error log"). (Section 6.3.2) Clarify that 'C' bit semantics are to release all resources, reallocate only those requested in message. (Section 6.4) What does client do with response; add MUST/SHOULD. DHCPv4 features to carry forward/misfeatures to avoid/missing features to add Extensibility framework: accommodate future extensions without requiring recoding/redeployment of clients Vendor identifier/vnedor-encapsulated options "Echo option" - client retains and echoes option value from server Explicit "change server" mechanism Client version option DHCPv4 current work to review Agent options Failover protocol: any features in base DHCPv6 spec that would make inter-server protocol easier to write? DHCP-DNS interaction DHCPv6 new features What must client do to support interaction with applications? Consistency across client implementations: List of client-supported options Client can explicitly reject options as unsupported/unrequested Alternative actions: what to do if option unrecognized, unrequested, ... Requested values: client gives range of desired values Model of "resources" and client-server management; what's the "right" model? What is a "resource"? What is "releasable"? How does renubmering work; e.g., through RECONFIGURE? Document structure Organization - unclear when reading; information duplicated, not in same part of document, contradictory. Mike Carney to add protocol overview Additional discussion needed about why complicated actions are mandated and how they were arrived at. WG to send input to authors about parts of the spec that require additional discussion. Consider merging two documents into one.