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