Update DESIGN

DESIGN

@@ -57,35 +57,8 @@ Goals:
 	a.  If we aren't required to sacrifice anything more
 	    important, it's always good to be frugal.
 
-
-Specifics:
-
-Implementation language will be C.  C is universally available, very
-predictable, and well accepted.  dhcp clients don't have to deal with
-complicated data structures or extensively with strings, so C's
-largest weaknesses should not be highly apparent.  On the other hand,
-dhcp clients must extensively deal with the OS in a low-level fashion.
-C's strongest points will therefore be used.
-
-More practically, a program written in a compiled language other than
-C will be poorly accepted by the average user.  Since widespread use
-is an eventual goal of ndhc, this point is very eloquent.
-
-For now, I'm taking advantage of the existing udhcpc.  With minor
-modifications, it will serve quite well as the dhcp client daemon.  It
-is then only necessary for me to write a client request translator
-and a interface change daemon.  The result should be a highly modular
-solution.
-
-I'm developing on a Linux-based platform.  ndhc will first be designed
-to work properly on a Linux-based system.  I will then make certain
-that ndhc works well on a RSBAC-enabled Linux system.  Afterwards, I
-_may_ spend some effort porting ndhc to FreeBSD (but don't count on it).  I
-have no personal interest in other platforms.
-
 Layout:
 
-
 ndhc daemon  (root -> chroot -> drop all !(CAP_NET_BROADCAST|CAP_NET_RAW) 
               -> nopriv)