CURRENT_MEETING_REPORT_ Reported by Ralph Droms/Bucknell Minutes of the Dynamic Host Configuration Working Group (DHC) The Working Group discussed the interface between DHCP and the Domain Name System (DNS). DHCP needs an interface that can allow dynamic updates to DNS entries in response to dynamic allocation of DNS names to DHCP clients. Rob Austein explained that the DNS Working Group is currently developing such an interface to DNS that considers the needs of DHCP. The Working Group discussed the possible use of SNMP with DHCP. SNMP may be useful as a ``second-level'' bootstrap mechanism to transmit additional configuration parameters to a client. SNMP is not likely to be as useful as an implementation-specific interface for server management. SNMP is an interesting candidate for the server-server protocol, as it may provide the semantics and data representation tools required for exchange of DHCP binding information between servers. The Working Group discovered a technical problem with the current definition of the `chaddr' field, which provides for use of `chaddr' as either a hardware address or other unique identifier. As the `chaddr' value must be used to return DHCP reply messages to the client, that field will be reserved for use strictly as a hardware address, and the client will be required to supply a unique identifier in a `client identifier' option. This identifier will be a typed value with the same structure as defined for the `chaddr' field. Mike Carney and Jon Dreyer submitted a new definition for encapsulating vendor-specific options that the Working Group accepted with minor modifications. In the accepted definition, the `vendor- specific information' option will include an initial value that identifies how to interpret the contents of the option, and other DHCP options, encoded in the same format as the current variable- length DHCP options. The initial identifying values will be centrally administered to avoid conflicts. One identifying value will be reserved for local use. The mechanism for determining the parameters returned to a particular client was discussed at length. The focal points of the discussion were the ways in which a client can identify its characteristics (`client type' option) and the rules by which a server can use those characteristics to choose the information to be returned to a host. No conclusion was reached at the meeting; an interim solution will be incorporated into the DHCP specification Internet-Draft to allow the protocol to move forward to Proposed Standard. Attendees Kannan Alagappan kannan@dsmail.lkg.dec.com Steve Alexander stevea@lachman.com 1 Philip Almquist almquist@jessica.stanford.edu Robert Austein sra@epilogue.com John Boatright bryan_boatright@ksc.nasa.gov Gregory Bruell gob@wellfleet.com Ralph Droms droms@bucknell.edu Robert Gilligan gilligan@Eng.Sun.Com Richard Harris rharris@atc.boeing.com John Hascall john@iastate.edu Roland Hedberg Roland.Hedberg@rc.tudelft.nl Ronald Jacoby rj@sgi.com Scott Kaplan scott@wco.ftp.com Frank Kastenholz kasten@ftp.com Mark Kepke mak@fc.hp.com Andrew Knutsen andrewk@sco.com Lakshman Krishnamurthy lakashman@ms.uky.edu Yu-Lin Lu yulin@hpinddu.cup.hp.com Paul Lustgraaf grpjl@iastate.edu Kent Malave kent@bach.austin.ibm.com Glenn Mansfield glenn@aic.co.jp Evan McGinnis bem@3com.com William Nowicki nowicki@legato.com William Owens owens@acsu.buffalo.edu Charles Perkins perk@watson.ibm.com Steven Richardson sjr@merit.edu Shawn Routhier sar@epilogue.com Jon Saperia saperia@lkg.dec.com Chris Shaw cshaw@banyan.com Marek Tomaszewski marek@net.com Walter Wimer walter.wimer@andrew.cmu.edu 2