Excerpts from netbsd: 17-Jun-97 Re: README: changes to conf.. Jonathan
Stone@DSG.Stanf (2717)
Excerpts from netbsd: 17-Jun-97 Re: README: changes to conf.. Ted
Lemon@hoffman.vix.co (768)

> DHCP does automatic address allocation, which may be either an
> advantage or not, depending on how you look at it.   Since it can also
> do static allocation if you prefer that, I think it's a win all
> around.   Of course, I'm somewhat biased... :')

OK, I'm getting convinced that it does at least not hurt...
(except the additional code), and that it can even be of use
in a diskless environment. (However, it is unlikely to have
a diskless machine booted via a dial-up line.)
Some technical questions below.

> A well-behaved DHCP client can send either.

I remember a time 1 or 2 years ago that the syslogs of my bootp
server machines got flooded with "bad addr len" complaints,
triggered by DHCP requests of windows PCs. 
It has taken a while to ki^H^Htell them how to disable DHCP
- they didn't really need it, they only had clicked at a checkbox
whose sense they didn't understand.
(bash$ wc /etc/hosts
    5522   13555  182495 /etc/hosts)
I guess these clients were not "well-behaved".

> Also, are we talking about PROM boot code in ethernet cards, or the
> in-kernel code for root-on-NFS that configures the kenerl's network
> stack?  Those aren't always the same.

They are of course not the same, but they should work coherently.
(Probably the DHCP server ID should be passed from the ROM
to the kernel somehow, if I understand the spec correctly.)
I hope that the additional code will fit into the EPROM.

> if your multi-subnet support can forward BOOTP requests and
> responses, across multiple subnets, then it can forward DHCP requests
> and responses.

It was actually a bit more: In my environment, he client gets a different
configuration depending on which subnet it is physically located in.
The bootptab can hold any number of entries for one hardware
address, the server scans for matching ones (using the requested filename
too) and sends the reply to the right subnet.
So I can take a client (mostly controllers for data acquisition front-end)
from one experiment (=1 subnet) to another without any administration.

Some technical questions (I only had a quick view at rfc2131 so far):
-Is this scenario acceptable?:
  ROM issues DISCOVER, takes first OFFER, sends
  REQUEST, gets ACK.
  Kernel sends REQEST with same server ID and uses address from ACK.
-Can the filename field in requests be used by the DHCP server?
  (I like the semantics to look up first <filename>.<hostname> and
  fall back to <filename>.)
-How would you manage to have different TFTP and NFS servers
  (TFTP for kernel, NFS for root file system) - there is only one
  "siaddr" field.
-Are there still user defined tags (ala T144)?

best regards
Matthias