> Are there any size-limitations for those binaries loaded via MOP ??

not officially, no.

> If binaries of (almost) arbitrary size can be loaded via MOP, then
> mop-ing a kernel with root on nfs and swap on nfs should be enough
> to install the machine, since all the neccessary drivers are included
> in the kernel.

dec does (did?) this with diskless ultrix.  what we found was that MOP
was highly sensitive to variable delay (e.g., from a congested ethernet
or busy server) and that losing the whole file and starting over was its
means of "error" "recovery".  anything up to 64KB or so is a safe bet.
anything above that is going to be frustrating if run on a live net.

> If it's not possible to load the kernel itself via MOP, then the
> copy-program needs to be augmented with some mehtods for network-access.
> Also edlabel needs some new standalone drivers, since the ROM-routines
> won't work for non boot-devices (SCSI comes to mind).

yes.  this is the right approach, except i wouldn't do it in copy.  the
boot program should already know how to do tftp, and it should already
know how to use dhcp or bootp to learn its name and kernel name and so on.
the right approach is to use MOP to load /boot and let /boot load /bsd.

> Another possibility would be to add network-functionality to the 
> /boot-program so that this program could load the kernel (root/swap
> on nfs) via network. Then initializing/installing the local disk would
> be the same as in the mopable kernel szenario.

much better in my opinion.  (and this is what we ended up doing with our
diskless DECstations since their kernels were so much larger than the VAX
ones).