> 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.

This is how dhcpd works as well.   In fact, it's incapable of working
any other way.

> -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.

If the BOOT proms provided this sort of support, this would be a
reasonable thing to do.   Although I would prefer that the boot PROM
be a little more picky about which address it takes.   Ideally, the
address acquired at the previous boot would be retained in EEPROM so
that the PROM could do an INIT-REBOOT (just a DHCPREQUEST) if
possible.   Right now this is a pipe dream, though.

> -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>.)

If you can document how this is supposed to work, and convince me that
it's reasonable, then I can implement it.   From what you've said so
far, I'm not sure what you mean.

> -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.

How about passing as the root filesystem name ``froboz:/roots/myclient''?

> -Are there still user defined tags (ala T144)?

Yes.   Actually, the protocol expands this somewhat, although
currently I don't support this as well as I'd like.

			       _MelloN_