Subject: FW: MDHCP Questions

From: "Hibbs, R BARR (PB-rbhibbs)" <[email-masked]>
Date: Thu, 3 Dec 1998 13:38:53 -0500 (EST)

Apologies to Ralph, et al.,  as I posted this reply directly to the malloc
list before the Thanksgiving holiday and did not copy any of the dhcp
mailing lists....

--Barr

----------
From:  Hibbs, R BARR (PB-rbhibbs)
Sent:  Monday, November 23, 1998 9:35 AM
To:  [email-masked]'
Subject:  MDHCP Questions

Steve Hanna asked the following questions of the DHCP Working Group:

1)	Do you think that you might implement an MDHCP client or server?
2)	If you were to do so, would you attempt to share code with your DHCP
client or server?
3)	Do you think that we should continue to maintain a similarity
between MDHCP and DHCP? Why or why not?

In our enterprise, the services we offer to network clients depend upon the
demand for those services and the willingness of the first client to pay a
significant portion of the development cost;  implementation costs are
generally shared among all clients.  So, if we implement an MDHCP server
(our users would have to obtain a commercial client that implements MDHCP)
it would be only if sufficient demand existed for it -- somewhat of a
"chicken and egg" problem.  I can anticipate that such a service might be
requested in the future, but can't imagine when the demand for it will
arise.

When requested to implement an MDHCP server, we would most definitely
attempt to share (or re-use) code with our DHCP server.  There is sufficient
similarity between the two protocols that such re-use seems prudent as a way
of leveraging our investment in the development, implementation, and support
infrastructure for DHCP.

As for maintaining similarity between the two protocols, I see several
relevant points:

1)	By choosing to name the two protocols in a similar way, a casual
observer would expect the similarities to extend beyond the name to message
formats and protocol exchanges.  If the two protocols diverge significantly
by design, then I suggest that the name MDHCP be changed to avoid confusion
with RFC 2131.
2)	Again, if the protocols diverge significantly, then perhaps the
message formats should avoid similarity and the protocol messages be renamed
to avoid confusion with RFC 2131.
3)	Instead of using the same format for options data as RFCs 2131 and
2132, consider coordinating the MDHCP options with the expanded options
format now being [occasionally] discussed in the DHCP Futures Panel:  by
agreement between the two Working Groups, it would be possible to declare
non-overlapping options space so that the questions raised about similar,
but inexact, options and the re-use or overlay of option numbers becomes
moot.

--Barr Hibbs
  Pacific*Bell
  666 Folsom Street, Room 1225
  San Francisco, CA  94107-1384
  +1-(415)-545-1576