diff --git a/crm/crm-1.0.dtd b/crm/crm-1.0.dtd
index c0b444942a..bde93ef9d4 100644
--- a/crm/crm-1.0.dtd
+++ b/crm/crm-1.0.dtd
@@ -1,549 +1,542 @@
 <?xml version="1.0" ?>
 
 <!-- This document describes the XML elements used by the CRM. 
   
   The DTD given here is an annotated syntax definition.
   
   GLOBAL TODOs:
 	- Versionize DTD so we can validate against a specific version
 	- Timestamps et al should probably not be CDATA but more
 	  specific types
 -->
 
 <!--
 
 The CIB is described quit well in section 5 of the crm.txt (checked into
 CVS in the crm directory) so it is not repeated here.  Suffice to say
 that it stores the configuration and runtime data required for
 cluster-wide resource managment in XML format.
 
 Because of inter-version compatibility, we cannot directly validate the
 CIB against this DTD; there may be fields present the local node cannot
 deal with. But the DTD can still be used as a tool to validate whether
 the output from the admin frontends is valid, and thus serves as a tool
 for debugging.
 
 CIB: Information Structure
 ===========================
 The CIB is divided into two main sections: The "static" configuration
 part and the "dynamic" status.
 
 The configuration contains - suprisingly - the configuration of the
 cluster, namely node attributes, resource instance configuration, and
 the constraints which describe the dependencies between all these. To
 identify the most recent configuration available in the cluster, this
 section is timestamped with the unique timestamp of the last update.
 
 The status part is dynamically generated / updated by the CRM system and
 represents the current status of the cluster; which nodes are up, down
 or crashed, which resources are running where etc. The timestamps here
 represent when the last change went into this section.
 
 All timestamps are given in seconds since the epoch with millisecond
 precision. 
 
 Every information carrying object has an "id" tag, which is basically
 the UUID of it, should we ever need to access it directly.
 
 More details are given in the annotated DTD below.
 
 -->
 
 <!-- Either configuration or status must be present. Why else would you
      have a CIB? -->
 <!ELEMENT cib (configuration?, status?)>
 
 <!-- TODO: Is the version element necessary? If we flag the DTD against
      which the CIB validates, the version is implicit... -->
 
 <!ATTLIST cib
           version      CDATA       #REQUIRED
           timestamp    CDATA       #REQUIRED>
 
 <!ELEMENT configuration (nodes, resources, constraints)>
 <!-- The most uptodate configuration in the cluster is automatically
      determined by the CRM via the timestamp; the source indicates
      which node that was. In case of updates at runtime, the source
      should be set to the node from which the last update occured.
 
      The serial gets incremented by one for any update to the
      configuration.
 
      TODO: Same comment about the version applies.
  -->
 
 <!ATTLIST configuration
           version      CDATA       #REQUIRED
           source       CDATA       #REQUIRED
 	  serial       CDATA	   #REQUIRED
           timestamp    CDATA       #REQUIRED>
 
 <!ELEMENT nodes       (node*)>
 
 <!-- Each node can have additional attributes, such as "connected to SAN
      subsystem whatever", and then a constraint could include a
      dependency on such an attribute being present or having a specific
      value. -->
 <!ELEMENT node (attributes?)>
 <!-- 
      Description is opaque to the CRM, some adminstrative comments.
 
      dc_weight is an optional weight for influencing the DC election
      process...
 
      TODO: Do we need to know about ping nodes...?
      -->
 <!ATTLIST node
           id            CDATA #REQUIRED
 	  uname		CDATA #REQUIRED
           description   CDATA #IMPLIED
 	  dc_weight	CDATA #IMPLIED
           type          (node|ping) #REQUIRED>
 
 <!-- RESOURCES -->
 
 <!ELEMENT resources   (resource*)>
 
 <!-- TODO: Where should we place a version requirement of the resource
 	   agent? Is that a resource attribute, or a constraint...? 
 	   Same for the resource priority, I guess. -->
 <!ELEMENT resource (instance_attributes*)>
 <!ATTLIST resource
           id            CDATA #REQUIRED
           description   CDATA #IMPLIED
           class         (ocf|init|heartbeat)	#REQUIRED
 	  ra_version	CDATA #IMPLIED
 	  priority      CDATA #IMPLIED
           type          CDATA #REQUIRED>
 
 <!-- Some of these may need to be overridden on a per-node /
      per-node-attribute basis (ie, eth1 is eth0 on some nodes...). Same
      is true for timings.
      
      This is expressed as follows: You can have multiple sets of
      'instance attributes'. The one with the highest weight is chosen.
 
      Otherwise, if a matching node_ref is found, the instance parameters
      there override the defaults completely; the node_ref list is
      evaluated ordered by the no tag. The weight attribute doesn't make
      much sense here.
      -->
 <!ELEMENT instance_attributes (node_ref?, parameters?, timings?)>
 <!ATTLIST instance_attributes
 	  weight	CDATA #IMPLIED
 	  id		CDATA #REQUIRED>
 
 <!-- Can override the default timeouts or frequencies. Times are given
      in seconds, millisecond precision is permitted.
      -->
 <!ELEMENT timings (timing+)>
 
 <!ELEMENT timing EMPTY>
 <!ATTLIST timing
 		id	CDATA #REQUIRED
 		action	CDATA #REQUIRED
 		timeout CDATA #IMPLIED
 		frequency CDATA #IMPLIED>
 
 <!-- CONSTRAINTS -->
 <!ELEMENT constraints
 (rsc_to_rsc*,rsc_to_node*,node_baseweight*,node_track*)>
 
 <!-- Every constraint entry also has a 'lifetime' attribute, which
      expresses when this is applicable. For example, a constraint could
      be purged automatically when a node reboots, or after a week.
 
      TODO: The syntax of this one needs more definition... -->
 
 <!-- Express dependencies between the elements.
      
      The type specifies whether or not a resource affects the start/stop
      ordering (ie, that resource 'from' should be started after 'to'),
      or whether it's a placement dependency (ie, 'from' should run on the
      same node as 'to').
 
      The 'strength' describes how strong the dependency is (RFC-style):
      
      An ordering dependency of strength 'must' implies that a resource
      must be started after another one; it will not work without the
      other one being present. If it was 'should' only, the resource will
      be started afterwards, but still be started if it is not present.
      
      An ordering dependency of "must not" would imply the opposite; if
      some higher priority resource has led to the 'to' being activated,
      this resource will not be run.
 
      The placement policies work in the same fashion.
 
      TODO: Are may/may not applicable at all? Should & Must are, because
      they control whether or not a failure to meet a requirement
      propagates upwards.
  -->
 <!ELEMENT rsc_to_rsc EMPTY>
 <!ATTLIST rsc_to_rsc
 		id	CDATA #REQUIRED
 		from	CDATA #REQUIRED
 		to	CDATA #REQUIRED
 		lifetime CDATA #IMPLIED
 		timestamp CDATA #REQUIRED
 		type	(ordering|placement) #REQUIRED
 		strength (must|should|may|maynot|shouldnot|mustnot) #REQUIRED>
 
 <!-- Specify which nodes are eligible for running a given resource. 
      
      During processing, all rsc_to_node for a given rsc are evaluated.
      
      All nodes start out with their base weight (which defaults to zero,
      but can be modified via a node_baseweight dependency), and then all
      matching rsc_to_node constraints modify their weight; it is either
      in- or decremented accordingly.
 
      "set" is different, the first set will finalize the score for the
      matching nodes.
 
      Then the highest non-zero available node is determined to place the
      resource.
      
      The rsc references, suprisingly, a resource id.
 
   -->
 <!ELEMENT rsc_to_node (node_ref)>
 <!ATTLIST rsc_to_node
 		lifetime CDATA #IMPLIED
 		timestamp CDATA #IMPLIED
 		id	CDATA #REQUIRED
 		weight  CDATA #IMPLIED
 		modifier (set|inc|dec) 'inc'
 		rsc	CDATA #REQUIRED>
 
 <!-- 
      This is similar, but works in the opposite direction; it allows the
      user to express a constraint on a (list of) node(s) identified by
      attribute or name, and which in turn affects the placement of /all/
      resources.
 
      Basically it allows the user to modify the "base weight" of a node.
 
      The most common case will be to "blacklist" a set of nodes; a
      negative weight will prevent them from being considered eligible
      anywhere, ie use a "set" to -1 or somesuch.
 
      A higher base-weight could be used to express a global preference.
      All nodes which are eligible to run a given resource will receive
      this weight as their 'default' weight (instead of 0). Caveat
      emperor: this will make the node a candidate to run all resources
      by default.  -->
 
 <!ELEMENT node_baseweight (node_ref+)>
 <!ATTLIST node_baseweight
 		lifetime CDATA #IMPLIED
 		timestamp CDATA #IMPLIED
 		weight	CDATA #REQUIRED
 		modifier (set|inc|dec) 'inc'
 		id	CDATA #REQUIRED>
 
 <!-- Reference a set of nodes, either by directly specifying a node id,
      uname, or by matching its attributes. All rules need to match.
      
      (You can express "OR" by having multiple rsc_to_node / node_baseweight
      entries.)
   -->
 <!ELEMENT node_ref (node_match+)>
 <!ATTLIST node_ref
 		id	CDATA #REQUIRED>
 
 <!ELEMENT node_match EMPTY>
 <!ATTLIST node_match
 		id	CDATA #REQUIRED
 		target	CDATA #REQUIRED
 		type	(id|uname|has_attr|not_attr|attr_value) #REQUIRED
 		value	CDATA #IMPLIED>
 
 
 <!-- STATUS SECTION -->
 <!-- Details about the status of each node configured.
 
  In places, a "source" attribute has been added so that the CRM is able
  to know where this information came from.  This is helpful during the
  merging process (performed by a new DC and perhaps periodically) as it
  allows the CRM to allow nodes to be authoritive about themselves if
  appropriate (ie. which resources it is running, but perhaps not always
  about its own health). TODO: Clarify meaning.
  
   To avoid duplication of data, state entries only carry references to
   nodes and resources. 
 
   TODO: Where is the status of on-going STONITH requests tracked?
   (Andrew: I believe this is now covered by the "unclean" attribute.  
   Unless "assassin" is also required to track who shot the node.)
   
 -->
 <!ELEMENT status (crm_state,node_state*)>
 
 
 <!-- Information about the CRM Layer of the cluster.
 
 	"dc_uname" is the uname of the currently elected as DC.
 
 	More attributes may be added later point.
 
 -->
 <!ELEMENT crm_status EMPTY>
 <!ATTLIST crm_status 
 	id	   CDATA #REQUIRED
 	dc_uname   CDATA #REQUIRED>
 
 
 <!-- 	The state of a given node.  
 	
 	This information is updated by the DC based on inputs from 
 	sources such as the CCM, status messages from remote LRMs and 
 	requests from other nodes. 
 
 	"id" is the node's uname.
 
 	"state" is either active (both CRM and CCM are up and the node 
 	is fully active in the cluster), in_ccm (node is around in the 
 	membership, but not taking part in CRM activities) or down
 	(neither).
 	
 	"unclean" is set to the current time when the node leaves the 
 	cluster ungracefully and is usually an indication that the node 
 	needs to be shot.  
 
 	The DC will unset this field after the Transitioner has successfully 
 	shot the node, OR the node rejoins the cluster cleanly.
 
 	"exp_state" is our expectation of the state. This requires some
 	book-keeping on the part of the other nodes to remember the last
 	state of any other node by updating it to the latest relayed to
 	them.
 	
 	"source" then states which node contributed this state entry.
 	If unclean is not set, then "source" refers to the node that
 	last updated the "state" attribute.  Otherwise, it will contain
 	the node who completed the STONITH operation.  
 
 	NOTE: There is a period of time between when we recognise the node
 	is unlean and when it is shot.  Perhaps an "assassin" attribute is 
 	needed or "source" should be unset when a node is detected as being 
 	unclean.
 
-	"health" the list of possible values for this attribute need 
-	to be fleshed out but the intention is to allow the PE to 
-	differentiate (when trying to place resources) between a healthy
-	node in the active state and one that is overloaded or performing 
-	recovery activities.
-
  	A node which is exp_state == down && state == active is, in
 	fact, going down. The Policy Engine will migrate resources away
 	from it.
 	
 	Ideally, there should be a node_state entry for every entry in
 	the <nodes> list.
 -->
 <!ELEMENT node_state (lrm, attributes)>
 <!ATTLIST node_state
 	id		CDATA			#REQUIRED
 	state	  	(active|in_ccm|down)	#REQUIRED
 	unclean		CDATA			#REQUIRED
 	exp_state	(active|down)		#REQUIRED
 	source		CDATA			#IMPLIED
-	health		(ok|overloaded|recovery|sick)	'ok'
 	timestamp	CDATA			#REQUIRED>
 
 <!-- Information from the Local Resource Manager of the node.
      
      Running resources, installed Resource Agents etc. -->
      
 <!ELEMENT lrm (lrm_resources,lrm_agents)>
 <!ATTLIST lrm
         id      CDATA #REQUIRED
 	version	CDATA #REQUIRED>
 
 <!-- TODO: Need to define howto handle agents provided by multiple
      sources. The OCF RA spec allows a resource type to be provided by
      multiple Resource Agents; how do we deal with that? -->
 <!ELEMENT lrm_agents (lrm_agent*)>
 
 <!ELEMENT lrm_agent (resource-agent?)>
 <!ATTLIST lrm_agent
 	type	CDATA #REQUIRED
 	class	(ocf|init|heartbeat) #REQUIRED
 	version CDATA #REQUIRED>
 
 <!-- TODO: In fact, this should reference the OCF RA DTD for class ==
 	   ocf, but I don't know how to specify that ;-) -->
 <!ELEMENT resource_agent EMPTY>
 
 <!ELEMENT lrm_resources (rsc_state*)>
 
 <!ELEMENT rsc_state EMPTY>
 <!ATTLIST rsc_state
           id		CDATA #REQUIRED
           rsc_id	CDATA #REQUIRED
           node_id	CDATA #IMPLIED
 	  rsc_state	(stopped|starting|started|fail|restarting|stopping|stop_fail)
 	  			#REQUIRED
           timestamp	CDATA #REQUIRED>
 
 <!-- ============================================================== -->
 <!-- ============================================================== -->
 
 <!--
  The Transition Graph is an ordered list of synapses, which consist of a
  list of pre-conditions (events) they are waiting for / triggering on
  and a (list of) actions which are initiated when they "fire". The first
  synapse to have a matching input "consumes" the event unless specified
  differently.
  
 -->
 
 <!ELEMENT transition_graph (synapse*)>
 
 <!-- When all inputs to a synapse are satisfied, the synapse fires the
      actions.
      
      "reset" states whether after having fired once, the synapse resets
      and accepts input again. "no": After having fired, the synapse
      becomes completely inactive. "yes": it completely resets. "greedy":
      The synapse will still 'consume' input, but not fire again.
 -->
 
 <!ELEMENT synapse (inputs,actions)>
 <!ATTLIST synapse
 	  id	CDATA #REQUIRED
 	  reset	(no|yes|greedy) 'greedy'>
 
 <!ELEMENT inputs (trigger+)>
 
 <!-- event_spec specifies the event we are looking for.
      This can be anything from "rsc foo started somewhere / on node X",
      "STONITH of node A completed", "DEFAULT" etc... 
 
      If an event is "consumed", no further inputs in other synapses will
      be triggered by it. If "no", the event will pass through,
      triggering us but otherwise completely unaltered. If "marks", we
      simply remember that the event has been accepted somewhere, but
      pass it on.
      
 -->
 <!ELEMENT trigger (rsc_state*,node_state*,pseudo_event*,crm_event*)>
 <!ATTLIST trigger
 	  id		CDATA #REQUIRED
 	  consumes	(no|yes|marks) 'marks'>
 
 
 <!-- STONITH events end up being rsc_ops; remember that we hope to
      simply invoke 'STONITH Resource Agent' and feed it with appropriate
      parameters.
 
   -->
 <!ELEMENT actions (rsc_op*,pseudo_event*,crm_event*)>
 
 <!-- The resource object inside the rsc_op object differs from the
      resources list only in content, not in syntax.
      - it is pre-processed, ie there's a maximum of one set of
        instance_parameters
      
      on_node is the uname of the node on which to trigger the operation.
 
      The operation is the command passed to the Resource Agent.
 -->
 
 <!ELEMENT rsc_op (resource)>
 <!ATTLIST rsc_op
 	id	CDATA #REQUIRED
 	on_node	CDATA #REQUIRED
 	operation	CDATA	#REQUIRED>
 
 <!-- For added flexibility, an action can trigger an event, which is
      then consumed somewhere else. Woah. Cool. -->
 <!ELEMENT pseudo_event EMPTY>
 <!ATTLIST pseudo_event
 	id	CDATA #REQUIRED>
 	
 <!-- crm_event: We can instruct a crmd to sign-out cleanly, or to
      retrigger the DC election.
      TODO: What else? We can hardly ask it to come up... ;-)
 -->
 <!ELEMENT crm_event EMPTY>
 <!ATTLIST crm_event
 	id	CDATA #REQUIRED
 	on_node	CDATA #REQUIRED
 	operation (shutdown|signup|election) #REQUIRED>
 
 <!-- ============================================================== -->
 <!-- ============================================================== -->
 
 <!-- crm_message: The messages we exchange between components and over
      the network. 
 
 	For type == reply, reference references the id of the original
 	msg.
   -->
 
 <!ELEMENT crm_message (msg_addr,msg_addr,operation,op_reply?,msg_data)>
 <!ATTLIST crm_message
           version	CDATA '1'
 	  type		(request|reply)	#REQUIRED
 	  id		CDATA		#REQUIRED
 	  reference	CDATA		#IMPLIED
           timestamp	CDATA		#REQUIRED>
 
 <!ELEMENT msg_addr EMPTY>
 <!ATTLIST msg_addr
 	part		(src|dst)	#REQUIRED
 	subsystem	(dc|crmd|dcib|cib|pe|te|lrm|admin) #REQUIRED
 	host		CDATA		#IMPLIED>
 
 <!-- What kinds of payload do we carry:
      op_reply	A generic reply message to a request
 
      TODO: Can msg_data not simply be melted into crm_message, cutting
      out one level of redirection?  
      (Andrew) Lets leave it separated least crm_message get too cluttered
 
      TODO: crm_message.type == reply is implicit if op_reply is present,
      should be merged
      (Andrew) Lets leave it in incase we want to piggyback requests on replies
 
      TODO: commands to pengine etc still need fleshing out /
      simplification or merge between various commands, ie "quit",
      "hello", "compute" etc should all be the same type, just different 
      contents - maybe generic_op + attributes?
      (Andrew) Well hurry up then, we dont have all year :)
 -->
 <!ELEMENT msg_data (rsc_op?,rsc_state?,lrm_state?,cib_fragment?)>
 
 <!-- need to flesh out the types of operations -->
 <!ELEMENT operation (nvpair*)>
 <!ATTLIST operation
 	  op		(noop|query|replace|add|delete)	'noop'
           verbose	(true|false)	#IMPLIED
 	  timeout	CDATA	#REQUIRED>
 
 <!-- verbose reply for user consumption, may be useful. -->
 <!ELEMENT op_reply EMPTY>
 <!ATTLIST op_reply
 	  result	(ok|fail)	#REQUIRED
           verbose	CDATA		#IMPLIED
           timestamp	CDATA		#REQUIRED>
 
 <!-- ============================================================== -->
 <!-- ============================================================== -->
 <!-- Common elements -->
 
 <!ELEMENT nvpair EMPTY>
 <!-- No, you don't /have/ to give a value. There's a difference between
      a key not being present and a key not having a value. -->
 <!ATTLIST nvpair
 	  id		CDATA #REQUIRED
 	  name		CDATA #REQUIRED
 	  value		CDATA #IMPLIED>
 
 <!-- Same same, different names for clarity ;) -->
 <!ELEMENT attributes (nvpair*)>
 <!ELEMENT parameters (nvpair*)>