Subject: Re: MDHCP changes

From: Thomas Narten <[email-masked]>
Date: Thu, 01 Oct 1998 10:26:19 -0400

> > So how much opportunity for common code is left?  Is it enough to
> > merit any semblence of compatibility?

> There is still a plenty of opportunity for common code. The administration,
> ipaddress management are two big things.

Could you please elaborate a bit?

Seems like the administration/address management issues might be
server implementation issues and don't have a direct dependency on the
packet format used between clients/server. I.e., couldn't you have a
simple mapping layer between the packet formats and what the backend
code for the existing server wants?

Steve Hanna <[email-masked]> writes:

> We have also agreed to remove the chaddr, sname, and file fields from the packet 
> format. This will remove 208 of the 228 bytes currently devoted to reserved 
> fields within the MDHCP packet format. Removing more fields would make it 
> difficult to share any code between MDHCP and DHCP implementations.

which 20 bytes are left, and exactly what fields do they represent?
Is the issue that the information contained in those fields is needed
for compatability (in which case the packet format could potentially
be changed without loss of flexibility) or are the exact fields
(format/syntax/semantics) needed? Are those fields directly relevant
to malloc?

Thomas

---

From: Steve Hanna <[email-masked]>
Date: Thu, 1 Oct 1998 13:15:01 -0400 (EDT)

> > We have also agreed to remove the chaddr, sname, and file fields from the
> > packet format. This will remove 208 of the 228 bytes currently devoted to
> > reserved fields within the MDHCP packet format. Removing more fields would
> > make it difficult to share any code between MDHCP and DHCP implementations.
> 

The remaining reserved fields are: op (1 byte), htype (1), hlen (1), hops (1), 
secs (2), flags (2), ciaddr (4), siaddr (4), and giaddr (4). None of these 
fields are relevant to malloc. All of these fields are defined in the MDHCP spec 
as "Must be zero" (or something similar). They are retained in MDHCP only to 
make it easier to share code between DHCP and MDHCP implementation.

-Steve

---

From: Munil Shah <[email-masked]>
Date: Thu, 1 Oct 1998 21:21:04 -0700

>> The implementation which i have been able to reuse include header
formatting and parsing, options processing, stable store use/management and
the dhcp administration interface. By removing the 3 big fields from the
dhcp packet format (boot file name, server, hardware id) we can eliminate
the majority of unused fields without causing significant code changes to
the packet formatting and parsing. By keeping the packet format almost
similar we can reuse this portion of implementation on both client and the
server. 

Thanks, 
Munil

---

From: Vern Paxson <[email-masked]>
Date: Fri, 02 Oct 1998 13:54:23 PDT

> make it easier to share code between DHCP and MDHCP implementation.

I'm still not getting it.  How do must-be-zero fields, none of which are
relevant to malloc, help with sharing code?  There's nothing useful in the
fields, and I'm having trouble seeing how having the exact same packet format
can save more than a few lines of code.  I could see perhaps having the same
style of options as saving some code; but can somone please explain how the
presence of the empty fields on the wire is actually a significant win?

		Vern