Update TODO and requirements file

Signed-off-by: Lon Hohberger <lon@users.sourceforge.net>

TODO

@@ -1,9 +1,16 @@
-High Priority / Blockers:
+High Priority / Blockers for v1.0;
 
-* serial server-side listener/dispatcher
+* serial server-side listener/dispatcher.  This will allows the
+  source VM name to be known and passed as part of the fencing
+  request to the appropriate backend.
 
 * pacemaker backend
 
+* ability to pass the hostname, VM name, or VM UUID of the requesting
+  node to the backend.  This will allow better controls of who can
+  fence who (for example, "vm1 vm2 vm3" can all fence each other, while
+  none may fence "vm4 vm5 vm6" since they are in a different cluster).
+
 Future Stuff:
 
 * oVirt backend

fence_virt.txt

@@ -14,10 +14,12 @@ Requirements
 3. Nonrequirement of host clustering software.  Multiple layers of
    configuration sucks.  While I fundamentally disagree with the general
    idea that running CMAN on the host constitutes a "heavyweight
-   cluster", customer perception is important.
+   cluster", perception is important.
 
-4. Support for RHEV-M.  Be able to send fencing requests up to RHEV-M
-   for execution.  This is beneficial from a security standpoint.
+4. Ability to support RHEV-M, oVirt server, and other virtual machine
+   management technologies.  This is beneficial from a security standpoint
+   since it is assumed the management server will be aware of what VMs
+   are allowed to fence what other VMs.
 
 5. Upgrade compatibility with fence_xvm from a configuration standpoint.
    This may be provided by a symlink over fence_xvm.  If this feature
@@ -108,6 +110,7 @@ We propose at 5 plugins in this case:
    responsible for taking the appropriate action and responding to
    the request.
 
+
 These plugins have no requirements on which guest to host communication
 plugin is used (you could, if you wanted, use 'direct serial' with
 'cluster checkpoint', or 'multicast' with 'RHEV-H' for example).