diff --git a/ra/Makefile b/ra/Makefile
index 217b9b6..5a985f0 100644
--- a/ra/Makefile
+++ b/ra/Makefile
@@ -1,21 +1,19 @@
 # Basic DocBook mangling makefile. 
 #
 # 
 
 BASENAME=resource-agent-api
 
-DOCBOOK2HTML=docbook2html -u -d ../docbook-utils.dsl\#html
+.PHONY: all clean
 
-DOCBOOK2PS=docbook2ps -u -d ../docbook-utils.dsl\#print
+%.html: %.md
+	pandoc -f markdown -o $@ $^
 
-%.html: %.xml
-	$(DOCBOOK2HTML) $^
+%.pdf: %.md
+	pandoc -f markdown -o $@ $^
 
-%.ps: %.xml
-	$(DOCBOOK2PS) $^
-
-%.pdf: %.ps
-	ps2pdf $^
+all: $(BASENAME).pdf $(BASENAME).html
 
 clean:
-	rm $(BASENAME).pdf $(BASENAME).ps $(BASENAME).html||true
\ No newline at end of file
+	rm $(BASENAME).pdf $(BASENAME).html||true
+
diff --git a/ra/resource-agent-api.md b/ra/resource-agent-api.md
new file mode 100644
index 0000000..8cfef26
--- /dev/null
+++ b/ra/resource-agent-api.md
@@ -0,0 +1,493 @@
+# Open Clustering Framework Resource Agent API
+
+Editor: Lars Marowsky-Brée <lmb@suse.de>
+
+URL: http://www.opencf.org/standards/resource-agent-api.html
+
+## License
+
+    Copyright (c) 2002 Lars Marowsky-Brée.
+
+    Permission is granted to copy, distribute and/or modify this document
+    under the terms of the GNU Free Documentation License, Version 1.2 or
+    any later version published by the Free Software Foundation; with no
+    Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
+    copy of the license can be found at http://www.gnu.org/licenses/fdl.txt.
+
+## Abstract
+
+Resource Agents (RA) are the middle layer between the Resource Manager
+(RM) and the actual resources being managed. They aim to integrate the
+resource type with the RM without any modifications to the actual
+resource provider itself, by encapsulating it carefully and providing
+generic methods (actions) to operate on them.
+
+The RAs are obviously very specific to the resource type they operate
+on, however there is no reason why they should be specific to a
+particular RM.
+
+The API described in this document should be general enough that a
+compliant Resource Agent can be used by all existing resource managers /
+switch-over systems who chose to implement this API either exclusively
+or in addition to their existing one.
+
+
+### Scope
+
+This document describes a common API for the RM to call the RAs so the
+pool of available RAs can be shared by the different clustering
+solutions.
+
+It does NOT define any libraries or helper functions which RAs might share
+with regard to common functionality like external command execution, cluster
+logging et cetera, as these are NOT specific to RA and are defined in the
+respective standards.
+
+
+### API version described
+
+This document currently describes version 1.0 of the API. 
+
+
+## Terms used in this document
+
+### "Resource"
+
+A single physical or logical entity that provides a service to clients or
+other resources. For example, a resource can be a single disk volume, a
+particular network address, or an application such as a web server. A resource
+is generally available for use over time on two or more nodes in a cluster,
+although it usually can be allocated to only one node at any given time.
+
+Resources are identified by a name that must be unique to the particular
+resource type. This is any name chosen by the administrator to identify
+the resource instance and passed to the RA as a special environment
+variable.
+
+A resource may also have instance parameters which provide additional
+information required for Resource Agent to control the resource.
+
+
+### "Resource types"
+
+A resource type represents a set of resources which share a common set of
+instance parameters and a common set of actions which can be performed on
+resource of the given type.
+
+The resource type name is chosen by the provider of the RA.
+
+
+### "Resource agent"
+
+A RA provides the actions ("member functions") for a given type of
+resources; by providing the RA with the instance parameters, it is used
+to control a specific resource.
+
+They are usually implemented as shell scripts, but the API described here does
+not require this.
+
+Although this is somewhat similar to LSB init scripts, there are some
+differences explained below. 
+
+
+### "Instance parameters"
+
+Instance parameters are the attributes which describe a given resource
+instance. It is recommended that the implementor minimize the set of
+instance parameters.
+
+The meta data allows the RA to flag one or more instance parameters as
+`unique`. This is a hint to the RM or higher level configuration tools
+that the combination of these parameters must be unique to the given
+resource type.
+
+An instance parameter has a given name and value. They are both case
+sensitive and must satisfy the requirements of POSIX environment
+name/value combinations.
+
+
+## API
+
+### API Version Numbers
+
+The version number is of the form `x.y`, where `x` and `y` are positive
+numbers greater or equal to zero. `x` is referred to as the "major"
+number, and `y` as the "minor" number.
+
+The major number must be increased if a _backwards incompatible_ change is
+made to the API. A major number mismatch between the RA and the RM must be
+reported as an error by both sides.
+
+The minor number must be increased if _any_ change at all is made to the
+API.  If the major is increased, the minor number should be reset to
+zero. The minor number can be used by both sides to see whether a
+certain additional feature is supported by the other party.
+
+
+### Paths
+
+The Resource Agents are located in subdirectories under
+`/usr/ocf/resource.d`.
+
+The subdirectories allow the installation of multiple RAs for the same
+type, but from different vendors or package versions.
+
+The filename within the directories equals the resource type name
+provided by the RA and may be a link to the real location.
+
+Example directory structure:
+
+    FailSafe -> FailSafe-1.1.0/
+    FailSafe-1.0.4/
+    FailSafe-1.1.0/
+    heartbeat -> heartbeat-1.1.2/
+    heartbeat-1.1.2/
+    heartbeat-1.1.2/IPAddr
+    heartbeat-1.1.2/IP -> IPAddr
+
+How the RM choses an agent for a specific resource type name from the
+available set is implementation specific.
+
+
+### Execution syntax
+
+After the RM has identified the executable to call, the RA will be
+called with the requested action as its sole argument.
+
+To allow for further extensions, the RA shall ignore all other
+arguments.
+
+
+### Resource Agent actions
+
+A RA must be able to perform the following actions on a given resource
+instance on request by the RM; additional actions may be supported by
+the script for example for LSB compliance.
+
+The actions are all required to be idempotent. Invoking any operation
+twice - in particular, the start and stop actions - shall succeed and
+leave the resource instance in the requested state.
+
+In general, a RA should not assume it is the only RA of its type running
+at any given time because the RM might start several RA instances for
+multiple independent resource instances in parallel.
+
+_Mandatory_ actions must be supported; _optional_ operations must be
+advertised in the meta data if supported. If the RM tries to call a
+unsupported action the RA shall return an error as defined below.
+
+
+- `start`
+  
+    Mandatory.
+
+    This brings the resource instance online and makes it available for
+    use. It should NOT terminate before the resource instance has either
+    been fully started or an error has been encountered.
+
+    It may try to implement recovery actions for certain cases of startup
+    failures.
+
+    `start` must succeed if the resource instance is already running.
+
+    `start` must return an error if the resource instance is not fully
+    started.
+
+- `stop`
+
+    Mandatory.
+
+    This stops the resource instance. After the `stop` command has
+    completed, no component of the resource shall remain active and it
+    must be possible to start it on the same node or another node or an
+    error must be returned.
+
+    The `stop` request by the RM includes the authorization to bring down the
+    resource even by force as long data integrity is maintained; breaking
+    currently active transactions should be avoided, but the request to offline
+    the resource has higher priority than this. If this is not possible,
+    the RA shall return an error to allow higher level recovery.
+
+    The `stop` action should also perform clean-ups of artifacts like leftover
+    shared memory segments, semaphores, IPC message queues, lock files etc.
+
+    `stop` must succeed if the resource is already stopped.
+
+    `stop` must return an error if the resource is not fully stopped.
+  
+- `monitor`
+
+    Mandatory.
+
+    Checks and returns the current status of the resource instance. The
+    thoroughness of the check is further influenced by the weight of the
+    check, which is further explained under **Action specific extensions**..
+
+    It is accepted practice to have additional instance parameters which
+    are not strictly required to identify the resource instance but are
+    needed to monitor it or customize how intrusive this check is allowed
+    to be.
+
+    Note that `monitor` shall also return a well defined error code (see
+    below) for stopped instances, ie before `start` has ever been
+    invoked.
+  
+- `recover`
+
+    Optional.
+
+    A special case of the `start` action, this should try to recover a resource
+    locally. 
+
+    It is recommended that this action is not advertised unless it is
+    advantageous to use when compared to a stop/start operation.
+
+    If this is not supported, it may be mapped to a stop/start action by
+    the RM.
+
+    An example includes "recovering" an IP address by moving it to another
+    interface; this is much less costly than initiating a full resource group
+    fail over to another node.
+
+- `reload`
+
+    Optional.
+
+    Notifies the resource instance of a configuration change external to
+    the instance parameters; it should reload the configuration of the
+    resource instance without disrupting the service.
+
+    It is recommended that this action is not advertised unless it is
+    advantageous to use when compared to a stop/start operation.
+
+    If this is not supported, it may be mapped to a stop/start action by
+    the RM.
+
+- `meta-data`
+
+    Mandatory.
+
+    Returns the resource agent meta data via stdout.
+
+- `validate-all`
+
+    Optional.
+
+    Validate the instance parameters provided.
+
+    Perform a syntax check and if possible, a semantic check on the
+    instance parameters.
+
+
+### Parameter passing
+
+The instance parameters and some additional attributes are passed in via the
+environment; this has been chosen because it does not reveal the parameters to
+an unprivileged user on the same system and environment variables can be
+easily accessed by all programming languages and shell scripts.
+
+The entire environment variable name space starting with `OCF_` is considered to
+be reserved for OCF use.
+
+
+#### Syntax for instance parameters
+
+They are directly converted to environment variables; the name is prefixed
+with `OCF_RESKEY_`.
+
+The instance parameter `force` with the value `yes` thus becomes
+`OCF_RESKEY_force=yes` in the environment.
+
+See the terms section on instance parameters for a more formal explanation.
+
+
+#### Global OCF attributes
+
+Currently, the following additional environment variables are defined:
+
+* `OCF_RA_VERSION_MAJOR`
+* `OCF_RA_VERSION_MINOR`
+
+    Version number of the OCF Resource Agent API. If the script does 
+    not support this revision, it should report an error.
+    
+    See **API Version Numbers** for an explanation of the versioning
+    scheme used. The version number is split into two numbers for ease
+    of use in shell scripts.
+
+    These two may be used by the RA to determine whether it is run under
+    an OCF compliant RM.
+
+    Example:
+
+    ```
+    OCF_RA_VERSION_MAJOR=1
+    OCF_RA_VERSION_MINOR=0
+    ```
+
+* `OCF_ROOT`
+
+    Referring to the root of the OCF directory hierarchy.
+    
+    Example: `OCF_ROOT=/usr/ocf`
+
+* `OCF_RESOURCE_INSTANCE`
+
+    The name of the resource instance.
+
+* `OCF_RESOURCE_TYPE`
+
+    The name of the resource type being operated on.
+
+### Action specific extensions
+
+These environment variables are not required for all actions, but only
+supported by some.
+
+#### Parameters specific to the 'monitor' action
+
+- `OCF_CHECK_LEVEL`
+
+    - `0`
+
+        The most lightweight check possible, which should not
+        have an impact on the QoS.
+
+        Example: Check for the existence of the process.
+
+    - `10`
+
+        A medium weight check, expected to be called multiple
+        times per minute, which should not have a noticeable
+        impact on the QoS.
+
+        Example: Send a request for a static page to a
+        webserver.
+
+    - `20`
+
+        A heavy weight check, called infrequently, which may
+        impact system or service performance.
+
+        Example: An internal consistency check to verify service
+        integrity.
+
+Service must remain available during all of these operation.
+All other number are reserved.
+
+It is recommended that if a requested level is not implemented,
+the RA should perform the next lower level supported.
+
+
+### Exit status codes
+
+These exit status codes are the ones documented in the LSB 1.1.0
+specification, with additional explanations of how they shall be used by
+RAs. In general, all non-zero status codes shall indicate failure in
+accordance to the best current practices.
+
+#### All operations
+
+- `0`
+
+    No error, action succeeded completely
+
+- `1`
+
+    Generic or unspecified error (current practice)
+    The "monitor" operation shall return this for a crashed, hung or
+    otherwise non-functional resource.
+
+- `2`
+
+    Invalid or excess argument(s)
+    Likely error code for validate-all, if the instance parameters
+    do not validate. Any other action is free to also return this
+    exit status code for this case.
+
+- `3`
+
+    Unimplemented feature (for example, "reload")
+
+- `4`
+
+    User had insufficient privilege
+
+- `5`
+
+    Program is not installed
+
+- `6`
+
+    Program is not configured
+
+- `7`
+
+    Program is not running
+
+    Note: This is not the error code to be returned by a successful
+    "stop" operation. A successful "stop" operation shall return 0.
+    The "monitor" action shall return this value only for a 
+    _cleanly_ stopped resource. If in doubt, it should return 1.
+
+- `8-99`
+
+    Reserved for future LSB use
+
+- `100-149`
+
+    Reserved for distribution use
+
+- `150-199`
+
+    Reserved for application use
+
+- `200-254`
+
+    Reserved
+
+## Relation to the LSB
+
+It is required that the current LSB spec is fully supported by the system.
+
+The API tries to make it possible to have RA function both as a normal LSB
+init script and a cluster-aware RA, but this is not required functionality.
+The RAs could however use the helper functions defined for LSB init scripts.
+
+
+## RA meta data
+
+### Format
+
+The API has the following requirements which are not fulfilled by the
+LSB way of embedding meta data into the beginning of the init scripts:
+
+- Independent of the language the RA is actually written in,
+- Extensible,
+- Structured,
+- Easy to parse from a variety of languages.
+
+This is why the API uses simple XML to describe the RA meta data. The
+DTD for this API can be found at [this location](http://www.opencf.org/standards/ra-api-1.dtd).
+
+### Semantics
+
+An example of a valid meta data output is provided in
+`ra-metadata-example.xml`.
+
+## To-do list
+
+- Move the terminology definitions out into a separate document
+  common to all OCF work.
+- An interface where the RA asynchronously informs the RM of
+  failures is planned but not defined yet. 
+
+## Contributors
+
+- James Bottomley <James.Bottomley@steeleye.com>
+- Greg Freemyer <freemyer@NorcrossGroup.com>
+- Simon Horman <horms@verge.net.au>
+- Ragnar Kjørstad <linux-ha@ragnark.vestdata.no>
+- Lars Marowsky-Brée <lmb@suse.de>
+- Alan Robertson <alanr@unix.sh>
+- Yixiong Zou <yixiong.zou@intel.com> 
diff --git a/ra/resource-agent-api.txt b/ra/resource-agent-api.txt
deleted file mode 100644
index 9774d79..0000000
--- a/ra/resource-agent-api.txt
+++ /dev/null
@@ -1,445 +0,0 @@
-DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
-
-0. Header
-
-Topic: Open Clustering Framework Resource Agent API
-Editor: Lars Marowsky-Brée <lmb@suse.de>
-Revision: $Id$
-URL: http://www.opencf.org/standards/resource-agent-api.txt
-
-Copyright (c) 2002 Lars Marowsky-Brée.
-
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
-copy of the license can be found at http://www.gnu.org/licenses/fdl.txt.
-
-
-1. Abstract
-
-Resource Agents (RA) are the middle layer between the Resource Manager
-(RM) and the actual resources being managed. They aim to integrate the
-resource type with the RM without any modifications to the actual
-resource provider itself, by encapsulating it carefully and providing
-generic methods (actions) to operate on them.
-
-The RAs are obviously very specific to the resource type they operate
-on, however there is no reason why they should be specific to a
-particular RM.
-
-The API described in this document should be general enough that a
-compliant Resource Agent can be used by all existing resource managers /
-switch-over systems who chose to implement this API either exclusively
-or in addition to their existing one.
-
-
-1.1. Scope
-
-This document describes a common API for the RM to call the RAs so the
-pool of available RAs can be shared by the different clustering
-solutions.
-
-It does NOT define any libraries or helper functions which RAs might share
-with regard to common functionality like external command execution, cluster
-logging et cetera, as these are NOT specific to RA and are defined in the
-respective standards.
-
-
-1.2. API version described
-
-This document currently describes version 1.0 of the API. 
-
-
-2. Terms used in this document
-
-2.1. "Resource"
-
-A single physical or logical entity that provides a service to clients or
-other resources. For example, a resource can be a single disk volume, a
-particular network address, or an application such as a web server. A resource
-is generally available for use over time on two or more nodes in a cluster,
-although it usually can be allocated to only one node at any given time.
-
-Resources are identified by a name that must be unique to the particular
-resource type. This is any name chosen by the administrator to identify
-the resource instance and passed to the RA as a special environment
-variable.
-
-A resource may also have instance parameters which provide additional
-information required for Resource Agent to control the resource.
-
-
-2.2. "Resource types"
-
-A resource type represents a set of resources which share a common set of
-instance parameters and a common set of actions which can be performed on
-resource of the given type.
-
-The resource type name is chosen by the provider of the RA.
-
-
-2.3. "Resource agent"
-
-A RA provides the actions ("member functions") for a given type of
-resources; by providing the RA with the instance parameters, it is used
-to control a specific resource.
-
-They are usually implemented as shell scripts, but the API described here does
-not require this.
-
-Although this is somewhat similar to LSB init scripts, there are some
-differences explained below. 
-
-
-2.4. "Instance parameters"
-
-Instance parameters are the attributes which describe a given resource
-instance. It is recommended that the implementor minimize the set of
-instance parameters.
-
-The meta data allows the RA to flag one or more instance parameters as
-'unique'. This is a hint to the RM or higher level configuration tools
-that the combination of these parameters must be unique to the given
-resource type.
-
-An instance parameter has a given name and value. They are both case
-sensitive and must satisfy the requirements of POSIX environment
-name/value combinations.
-
-
-3. API
-
-3.1. API Version Numbers
-
-The version number is of the form "x.y", where x and y are positive
-numbers greater or equal to zero. x is referred to as the "major"
-number, and y as the "minor" number.
-
-The major number must be increased if a _backwards incompatible_ change is
-made to the API. A major number mismatch between the RA and the RM must be
-reported as an error by both sides.
-
-The minor number must be increased if _any_ change at all is made to the
-API.  If the major is increased, the minor number should be reset to
-zero. The minor number can be used by both sides to see whether a
-certain additional feature is supported by the other party.
-
-
-3.2. Paths
-
-The Resource Agents are located in subdirectories under
-"/usr/ocf/resource.d".
-
-The subdirectories allow the installation of multiple RAs for the same
-type, but from different vendors or package versions.
-
-The filename within the directories equals the resource type name
-provided by the RA and may be a link to the real location.
-
-Example directory structure:
-	FailSafe -> FailSafe-1.1.0/
-	FailSafe-1.0.4/
-	FailSafe-1.1.0/
-	heartbeat -> heartbeat-1.1.2/
-	heartbeat-1.1.2/
-	heartbeat-1.1.2/IPAddr
-	heartbeat-1.1.2/IP -> IPAddr
-
-How the RM choses an agent for a specific resource type name from the
-available set is implementation specific.
-
-
-3.3. Execution syntax
-
-After the RM has identified the executable to call, the RA will be
-called with the requested action as its sole argument.
-
-To allow for further extensions, the RA shall ignore all other
-arguments.
-
-
-3.4. Resource Agent actions
-
-A RA must be able to perform the following actions on a given resource
-instance on request by the RM; additional actions may be supported by
-the script for example for LSB compliance.
-
-The actions are all required to be idempotent. Invoking any operation
-twice - in particular, the start and stop actions - shall succeed and
-leave the resource instance in the requested state.
-
-In general, a RA should not assume it is the only RA of its type running
-at any given time because the RM might start several RA instances for
-multiple independent resource instances in parallel.
-
-_Mandatory_ actions must be supported; _optional_ operations must be
-advertised in the meta data if supported. If the RM tries to call a
-unsupported action the RA shall return an error as defined below.
-
-
-3.4.1. start
-  
-  Mandatory.
-  
-  This brings the resource instance online and makes it available for
-  use. It should NOT terminate before the resource instance has either
-  been fully started or an error has been encountered.
-
-  It may try to implement recovery actions for certain cases of startup
-  failures.
-  
-  "start" must succeed if the resource instance is already running.
-  
-  "start" must return an error if the resource instance is not fully
-  started.
-
-3.4.2. stop
-
-  Mandatory.
-  
-  This stops the resource instance. After the "stop" command has
-  completed, no component of the resource shall remain active and it
-  must be possible to start it on the same node or another node or an
-  error must be returned.
-  
-  The "stop" request by the RM includes the authorization to bring down the
-  resource even by force as long data integrity is maintained; breaking
-  currently active transactions should be avoided, but the request to offline
-  the resource has higher priority than this. If this is not possible,
-  the RA shall return an error to allow higher level recovery.
-
-  The "stop" action should also perform clean-ups of artifacts like leftover
-  shared memory segments, semaphores, IPC message queues, lock files etc.
-
-  "stop" must succeed if the resource is already stopped.
-
-  "stop" must return an error if the resource is not fully stopped.
-  
-3.4.3. monitor
-
-  Mandatory.
-  
-  Checks and returns the current status of the resource instance. The
-  thoroughness of the check is further influenced by the weight of the
-  check, which is further explained in 3.5.3.
-
-  It is accepted practice to have additional instance parameters which
-  are not strictly required to identify the resource instance but are
-  needed to monitor it or customize how intrusive this check is allowed
-  to be.
-
-  Note that "monitor" shall also return a well defined error code (see
-  below) for stopped instances, ie before "start" has ever been
-  invoked.
-  
-3.4.4. recover
-
-  Optional.
-  
-  A special case of the "start" action, this should try to recover a resource
-  locally. 
-  
-  It is recommended that this action is not advertised unless it is
-  advantageous to use when compared to a stop/start operation.
-  
-  If this is not supported, it may be mapped to a stop/start action by
-  the RM.
-
-  An example includes "recovering" an IP address by moving it to another
-  interface; this is much less costly than initiating a full resource group
-  fail over to another node.
-
-3.4.5. reload
-
-  Optional.
-
-  Notifies the resource instance of a configuration change external to
-  the instance parameters; it should reload the configuration of the
-  resource instance without disrupting the service.
-
-  It is recommended that this action is not advertised unless it is
-  advantageous to use when compared to a stop/start operation.
-  
-  If this is not supported, it may be mapped to a stop/start action by
-  the RM.
-
-3.4.6. meta-data
-
-  Mandatory.
-  
-  Returns the resource agent meta data via stdout.
-
-3.4.7. validate-all
-
-  Optional.
-
-  Validate the instance parameters provided.
-
-  Perform a syntax check and if possible, a semantic check on the
-  instance parameters.
-
-
-3.5. Parameter passing
-
-The instance parameters and some additional attributes are passed in via the
-environment; this has been chosen because it does not reveal the parameters to
-an unprivileged user on the same system and environment variables can be
-easily accessed by all programming languages and shell scripts.
-
-The entire environment variable name space starting with OCF_ is considered to
-be reserved for OCF use.
-
-
-3.5.1. Syntax for instance parameters
-
-They are directly converted to environment variables; the name is prefixed
-with "OCF_RESKEY_".
-
-The instance parameter "force" with the value "yes" thus becomes:
-	OCF_RESKEY_force=yes
-in the environment.
-
-See section 4. for a more formal explanation of instance parameters.
-
-
-3.5.2. Global OCF attributes
-
-Currently, the following additional environment variables are defined:
-
-OCF_RA_VERSION_MAJOR
-OCF_RA_VERSION_MINOR
-	Version number of the OCF Resource Agent API. If the script does 
-	not support this revision, it should report an error.
-	
-	See 3.1. for an explanation of the versioning scheme used. The version
-	number is split into two numbers for ease of use in shell scripts.
-
-	These two may be used by the RA to determine whether it is run under
-	an OCF compliant RM.
-	
-	Example: OCF_RA_VERSION_MAJOR=1
-		 OCF_RA_VERSION_MINOR=0
-
-OCF_ROOT
-	Referring to the root of the OCF directory hierarchy.
-	
-	Example: OCF_ROOT=/usr/ocf
-
-OCF_RESOURCE_INSTANCE
-	The name of the resource instance.
-
-OCF_RESOURCE_TYPE
-	The name of the resource type being operated on.
-
-3.5.3. Action specific extensions
-
-These environment variables are not required for all actions, but only
-supported by some.
-
-3.5.3.1. Parameters specific to the 'monitor' action
-
-OCF_CHECK_LEVEL
-	0	The most lightweight check possible, which should not
-		have an impact on the QoS.
-		Example: Check for the existence of the process.
-	10	A medium weight check, expected to be called multiple
-		times per minute, which should not have a noticeable
-		impact on the QoS.
-		Example: Send a request for a static page to a
-		webserver.
-	20	A heavy weight check, called infrequently, which may
-		impact system or service performance.
-		Example: An internal consistency check to verify service
-		integrity.
-
-	Service must remain available during all of these operation.
-	All other number are reserved.
-
-	It is recommended that if a requested level is not implemented,
-	the RA should perform the next lower level supported.
-
-
-3.6. Exit status codes
-
-These exit status codes are the ones documented in the LSB 1.1.0
-specification, with additional explanations of how they shall be used by
-RAs. In general, all non-zero status codes shall indicate failure in
-accordance to the best current practices.
-
-3.6.1. All operations
-
-0	No error, action succeeded completely
-1 	generic or unspecified error (current practice)
-	The "monitor" operation shall return this for a crashed, hung or
-	otherwise non-functional resource.
-2 	invalid or excess argument(s)
-	Likely error code for validate-all, if the instance parameters
-	do not validate. Any other action is free to also return this
-	exit status code for this case.
-3 	unimplemented feature (for example, "reload")
-4 	user had insufficient privilege
-5 	program is not installed
-6 	program is not configured
-7 	program is not running
-	Note: This is not the error code to be returned by a successful
-	"stop" operation. A successful "stop" operation shall return 0.
-	The "monitor" action shall return this value only for a 
-	_cleanly_ stopped resource. If in doubt, it should return 1.
-8-99 	reserved for future LSB use
-100-149 reserved for distribution use
-150-199 reserved for application use
-200-254 reserved
-
-4. Relation to the LSB
-
-It is required that the current LSB spec is fully supported by the system.
-
-The API tries to make it possible to have RA function both as a normal LSB
-init script and a cluster-aware RA, but this is not required functionality.
-The RAs could however use the helper functions defined for LSB init scripts.
-
-
-5. RA meta data
-
-5.1. Format
-
-The API has the following requirements which are not fulfilled by the
-LSB way of embedding meta data into the beginning of the init scripts:
-
-- Independent of the language the RA is actually written in,
-- Extensible,
-- Structured,
-- Easy to parse from a variety of languages.
-
-This is why the API uses simple XML to describe the RA meta data. The
-DTD for this API can be found at
-http://www.opencf.org/standards/ra-api-1.dtd.
-
-5.2. Semantics
-
-An example of a valid meta data output is provided in
-ra-metadata-example.xml.
-
-
-C. To-do list
-
-Move the terminology definitions out into a separate document common to all
-OCF work.
-
-An interface where the RA asynchronously informs the RM of failures is planned
-but not defined yet. 
-
-D. Contributors
-
-	James Bottomley <James.Bottomley@steeleye.com>
-	Greg Freemyer <freemyer@NorcrossGroup.com>
-	Simon Horman <horms@verge.net.au>
-	Ragnar Kjørstad <linux-ha@ragnark.vestdata.no>
-	Lars Marowsky-Brée <lmb@suse.de>
-	Alan Robertson <alanr@unix.sh>
- 	Yixiong Zou <yixiong.zou@intel.com> 
-	
-E. Change Log
-
-DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
diff --git a/ra/resource-agent-api.xml b/ra/resource-agent-api.xml
deleted file mode 100644
index 54e831d..0000000
--- a/ra/resource-agent-api.xml
+++ /dev/null
@@ -1,888 +0,0 @@
-<?xml version="1.0" ?>
-<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-    "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-  <article>
-    <articleinfo>
-      <title>Open Clustering Framework Resource Agent API</title>
-      <authorgroup>
-	<editor>
-	  <firstname>Lars</firstname>
-	  <surname>Marowsky-Brée</surname>
-	  <affiliation>
-	    <address><email>lmb@suse.de</email></address>
-	  </affiliation>
-	</editor>
-      </authorgroup>    
-      <releaseinfo>$Id$</releaseinfo>
-      <copyright>
-	<year>2002</year>
-	<year>2003</year>
-	<holder>Lars Marowsky-Brée</holder>
-      </copyright>
-      <legalnotice>
-	<para>
-	  Permission is granted to copy, distribute and/or modify this
-	  document under the terms of the GNU Free Documentation
-	  License, Version 1.2 or any later version published by the
-	  Free Software Foundation; with no Invariant Sections, no
-	  Front-Cover Texts, and no Back-Cover Texts. A copy of the
-	  license can be found at http://www.gnu.org/licenses/fdl.txt.
-	</para>
-      </legalnotice>
-    </articleinfo>
-    
-    <section>
-      <title>Abstract</title> 
-    
-      <para>Resource Agents (RA) are the middle layer between the
-	Resource Manager (RM) and the actual resources being managed. They
-	aim to integrate the resource type with the RM without any
-	modifications to the actual resource provider itself, by
-	encapsulating it carefully and providing generic methods (actions)
-	to operate on them.
-      </para>
-
-      <para>The RAs are obviously very specific to the resource type
-	they operate on, however there is no reason why they should be
-	specific to a particular RM.
-      </para>
-
-      <para>The API described in this document should be general enough
-	that a compliant Resource Agent can be used by all existing
-	resource managers / switch-over systems who chose to implement
-	this API either exclusively or in addition to their existing one.
-      </para>
-      
-      <section>
-	<title>Scope</title>
-	
-	<para>This document describes a common API for the RM to call
-	  the RAs so the pool of available RAs can be shared by the
-	  different clustering solutions.
-	</para>
-
-	<para> It does NOT define any libraries or helper functions
-	  which RAs might share with regard to common functionality like
-	  external command execution, cluster logging et cetera, as
-	  these are NOT specific to RA and are defined in the respective
-	  standards.
-	</para>
-	
-      </section>
-      
-      <section>
-	<title>API version described</title>
-	
-	<para>
-	  This document currently describes version 1.0 of the
-	  API. </para>
-	
-      </section>
-      
-    </section>
-    
-    <section>
-      <title>Terms used in this document</title>
-
-      <section>
-	<title>"Resource"</title>
-	
-	<para>A single physical or logical entity that provides a
-	service to clients or other resources. For example, a resource
-	can be a single disk volume, a particular network address, or
-	an application such as a web server. A resource is generally
-	available for use over time on two or more nodes in a cluster,
-	although it usually can be allocated to only one node at any
-	given time.
-	</para>
-
-
-	<para>Resources are identified by a name that must be unique
-	to the particular resource type. This is any name chosen by
-	the administrator to identify the resource instance and passed
-	to the RA as a special environment variable.</para>
-
-	<para>A resource may also have instance parameters which
-	provide additional information required for Resource Agent to
-	control the resource.</para>
-	
-      </section>
-
-      <section>
-	<title>"Resource types"</title>
-	  
-	<para>A resource type represents a set of resources which
-	share a common set of instance parameters and a common set of
-	actions which can be performed on resource of the given
-	type.</para>
-	  
-	<para>The resource type name is chosen by the provider of the
-	RA.</para>
-      </section>
-
-      <section>
-	<title>"Resource agent"</title>
-
-	<para> A RA provides the actions ("member functions") for a
-	given type of resources; by providing the RA with the instance
-	parameters, it is used to control a specific resource.</para>
-
-	<para> They are usually implemented as shell scripts, but the
-	API described here does not require this.
-	</para>
-
-	<para>Although this is somewhat similar to LSB init scripts,
-	there are some differences explained below.</para>
-	
-      </section>
-
-      <section>
-	<title>"Instance parameters"</title>
-
-	<para>Instance parameters are the attributes which describe a
-	given resource instance. It is recommended that the
-	implementor minimize the set of instance parameters.</para>
-
-	<para>The meta data allows the RA to flag one or more instance
-	parameters as 'unique'. This is a hint to the RM or higher
-	level configuration tools that the combination of these
-	parameters must be unique to the given resource type.</para>
-
-	<para>An instance parameter has a given name and value. They
-	are both case sensitive and must satisfy the requirements of
-	POSIX environment name/value combinations.</para>
-
-      </section>
-
-    </section>
-
-    <section>
-      <title>API</title>
-      
-      <section>
-	<title>API Version Numbers</title>
-
-	<para>The version number is of the form "x.y", where x and y
-	are positive numbers greater or equal to zero. x is referred
-	to as the "major" number, and y as the "minor" number.
-	</para>
-
-	<para>The major number must be increased if a _backwards
-	incompatible_ change is made to the API. A major number
-	mismatch between the RA and the RM must be reported as an
-	error by both sides.
-	</para>
-
-	<para>The minor number must be increased if _any_ change at
-	all is made to the API.  If the major is increased, the minor
-	number should be reset to zero. The minor number can be used
-	by both sides to see whether a certain additional feature is
-	supported by the other party.  
-	</para> 
-
-      </section>
-
-      <section>
-	<title>Paths</title>
-
-	<para>The Resource Agents are located in subdirectories under
-	  <filename>/usr/ocf/resource.d</filename>.</para>
-
-	<para> The subdirectories allow the installation of multiple
-	RAs for the same type, but from different vendors or package
-	versions.</para>
-
-	<para>The filename within the directories equals the resource
-	type name provided by the RA and may be a link to the real
-	location.</para>
-
-	<para>Example directory structure:
-	  <screen>
-	FailSafe -> FailSafe-1.1.0/
-	FailSafe-1.0.4/
-	FailSafe-1.1.0/
-	heartbeat -> heartbeat-1.1.2/
-	heartbeat-1.1.2/
-	heartbeat-1.1.2/IPAddr
-	heartbeat-1.1.2/IP -> IPAddr
-	  </screen>
-	</para>
-
-	<para> How the RM chooses an agent for a specific resource type
-	name from the available set is implementation specific.</para>
-
-      </section>
-
-      <section>
-	<title>Execution syntax</title>
-	
-	<para>After the RM has identified the executable to call, the RA
-	  will be called with the requested action as its sole argument.
-	</para>
-	
-	<para>To allow for further extensions, the RA shall ignore all
-	  other arguments.
-	</para>
-	
-      </section>
-
-      <section>
-	<title>Resource Agent actions</title>
-
-	<para>A RA must be able to perform the following actions on a
-	given resource instance on request by the RM; additional
-	actions may be supported by the script for example for LSB
-	compliance.
-	</para>
-	
-	<para>The actions are all required to be idempotent. Invoking
-	any operation twice - in particular, the start and stop
-	actions - shall succeed and leave the resource instance in the
-	requested state.
-	</para>
-
-	<para>In general, a RA should not assume it is the only RA of
-	its type running at any given time because the RM might start
-	several RA instances for multiple independent resource
-	instances in parallel.
-	</para>
-	
-	<para><emphasis>Mandatory</emphasis> actions must be
-	supported; <emphasis>optional</emphasis> operations must be
-	advertised in the meta data if supported. If the RM tries to
-	call a unsupported action the RA shall return an error as
-	defined below.
-	</para>
-
-	<section>
-	  <title><command>start</command></title>
-	  
-	  <para><emphasis>Mandatory</emphasis>.</para>
-
-	  <para>This brings the resource instance online and makes it
-	  available for use. It should NOT terminate before the
-	  resource instance has either been fully started or an error
-	  has been encountered.</para>
-
-	  <para>It may try to implement recovery actions for certain
-	  cases of startup failures.</para>
-
-	  <para><command>start</command> must succeed if the
-	  resource instance is already running.</para>
-	
-	  <para><command>start</command> must return an error if
-	  the resource instance is not fully started.</para>
-	  
-	</section>
-
-	<section>
-	  <title><command>stop</command></title>
-
-	  <para><emphasis>Mandatory</emphasis>.</para>
-
-	  <para>This stops the resource instance. After the
-	  <command>stop</command> command has completed, no component
-	  of the resource shall remain active and it must be possible
-	  to start it on the same node or another node or an error
-	  must be returned.
-	  </para>
-
-	  <para> The <command>stop</command> request by the RM
-	  includes the authorization to bring down the resource even
-	  by force as long data integrity is maintained; breaking
-	  currently active transactions should be avoided, but the
-	  request to offline the resource has higher priority than
-	  this. If this is not possible, the RA shall return an error
-	  to allow higher level recovery.
-	  </para>
-
-	  <para> The <command>stop</command> action should also
-	  perform clean-ups of artifacts like leftover shared memory
-	  segments, semaphores, IPC message queues, lock files
-	  etc.</para>
-
-	  <para> <command>stop</command> must succeed if the resource
-	  is already stopped.
-	  </para>
-
-	  <para> <command>stop</command> must return an error if the
-	  resource is not fully stopped.
-	  </para>
-
-	</section>
-	
-	<section>
-	  <title><command>status</command></title>
-
-	  <para><emphasis>Mandatory</emphasis>.</para>
-
-	  <para>Checks and returns the current status of the resource
-	  instance. The thoroughness of the check is further
-	  influenced by the weight of the check, which is further
-	  explained in 3.5.3.
-	  </para>
-	  
-	  <para>It is accepted practice to have additional instance
-	  parameters which are not strictly required to identify the
-	  resource instance but are needed to monitor it or customize
-	  how intrusive this check is allowed to be.</para>
-
-	  <para> Note that <command>status</command> shall also return
-	  a well defined error code (see below) for stopped instances,
-	    ie before <command>start</command> has ever been invoked.
-	  </para>
-
-	</section>
-
-	<section>
-	  <title><command>recover</command></title>
-
-	  <para><emphasis>Optional</emphasis>.</para>
-
-	  <para> A special case of the <command>start</command>
-	  action, this should try to recover a resource locally.
-	  </para>
-
-	  <para>It is recommended that this action is not advertised
-	  unless it is advantageous to use when compared to a
-	  stop/start operation.
-	  </para>
-	  
-	  <para>If this is not supported, it may be mapped to a
-	  stop/start action by the RM.</para>
-
-	  <para>An example includes "recovering" an IP address by
-	  moving it to another interface; this is much less costly
-	  than initiating a full resource group fail over to another
-	  node.
-	  </para>
-	  
-	</section>
-
-	<section>
-	  <title><command>reload</command></title>
-	
-	  <para><emphasis>Optional</emphasis>.</para>
-
-	  <para>Notifies the resource instance of a configuration
-	  change external to the instance parameters; it should reload
-	  the configuration of the resource instance without
-	  disrupting the service.
-	  </para>
-
-	  <para>It is recommended that this action is not advertised
-	  unless it is advantageous to use when compared to a
-	  stop/start operation.</para>
-
-	  <para> If this is not supported, it may be mapped to a
-	  stop/start action by the RM.
-	  </para>
-
-	</section>
-	
-	<section>
-	  <title><command>metadata</command></title>
-
-	  <para><emphasis>Mandatory</emphasis>.</para>
-
-	  <para>Returns the resource agent meta data via stdout.</para>
-
-	</section>
-
-	<section>
-	  <title><command>validate-all</command></title>
-
-	  <para><emphasis>Optional</emphasis>.</para>
-
-	  <para>Validate the instance parameters provided.</para>
-
-	  <para> Perform a syntax check and if possible, a semantic
-	  check on the instance parameters.</para>
-
-	</section>
-
-      </section>
-
-      <section>
-	<title>	Parameter passing</title>
-
-	<para> The instance parameters and some additional attributes
-	are passed in via the environment; this has been chosen
-	because it does not reveal the parameters to an unprivileged
-	user on the same system and environment variables can be
-	easily accessed by all programming languages and shell
-	scripts.</para>
-
-	<para> The entire environment variable name space starting
-	with <varname>OCF_</varname> is considered to be reserved for
-	OCF use.</para>
-
-	<para>See section 4. for a more formal explanation of instance
-	parameters.</para>
-
-	<section>
-	  <title>Syntax for instance parameters</title>
-	  
-	  <para>They are directly converted to environment variables;
-	    the name is prefixed with <varname>OCF_RESKEY_</varname>.
-	  </para>
-
-	  <para>The instance parameter <varname>force</varname>" with
-	  the value <literal>yes</literal> thus becomes:
-	  <varname>OCF_RESKEY_force</varname>=<literal>yes</literal>
-	  in the environment. </para>
-
-	</section>
-
-	<section>
-	  <title> Global OCF attributes</title>
-
-	  <para> Currently, the following additional environment
-	  variables are defined:
-
-	    <variablelist>
-	      <varlistentry>
-		<term><varname>OCF_RA_VERSION_MAJOR</varname></term>
-		<term><varname>OCF_RA_VERSION_MINOR</varname></term>
-		<listitem>
-		  <para> Version number of the OCF Resource Agent
-		  API. If the script does not support this revision,
-		  it should report an error.
-		  </para>
-		  
-		  <para> See 3.1. for an explanation of the versioning
-		  scheme used. The version number is split into two
-		  numbers for ease of use in shell scripts.
-		  </para>
-		  
-		  <para> These two may be used by the RA to determine
-		  whether it is run under an OCF compliant RM.
-		  </para>
-		  
-		  <para> 
-		    Example: 
-		    <screen>	OCF_RA_VERSION_MAJOR=1
-	OCF_RA_VERSION_MINOR=0</screen>
-		  </para>
-		</listitem>
-	      </varlistentry>
-
-	      <varlistentry>
-		<term><varname>OCF_ROOT</varname></term>
-		<listitem>
-		  <para>Referring to the root of the OCF directory
-		  hierarchy.</para>
-
-		  <para> Example: 
-		    <screen>	OCF_ROOT=/usr/ocf</screen>
-		  </para>
-		</listitem>
-	      </varlistentry>
-
-	      <varlistentry>
-		<term><varname>OCF_RESOURCE_INSTANCE</varname></term>
-		<listitem>
-		  <para>The name of the resource instance.</para>
-		</listitem>
-	      </varlistentry>
-
-	      <varlistentry>
-		<term><varname>OCF_RESOURCE_TYPE</varname></term>
-		<listitem>
-		  <para> The name of the resource type being operated
-		  on.</para>
-		</listitem>
-	      </varlistentry>
-	    </variablelist>
-	  </para>
-	</section>
-	
-
-	<section>
-	  <title> Action specific extensions</title>
-
-	  <para>These environment variables are not required for all
-	  actions, but only supported by some.
-	  </para>
-
-	  <section>
-	    <title>Parameters specific to the 'status' action</title>
-	    
-	    <variablelist>
-	      <varlistentry>
-		<term><varname>OCF_CHECK_LEVEL</varname></term>
-		<listitem>
-		  <informaltable>
-		    <tgroup cols="2">
-		      <tbody>
-			<row>
-			  <entry>0</entry> 
-
-			  <entry>
-
-			    <simpara>The most lightweight check
-			    possible, which should not have an impact
-			    on the QoS.</simpara>
-
-			    <simpara>Example: Check for the existence
-			    of the process.</simpara></entry>
-			</row>
-
-			<row>
-			  <entry>10</entry> 
-
-			  <entry>
-			    
-			    <simpara>A medium weight check, expected
-			    to be called multiple times per minute,
-			    which should not have a noticeable impact
-			    on the QoS.</simpara> 
-
-			    <simpara>Example: Send a request for a
-			    static page to a webserver.</simpara>
-			  </entry> 
-			</row>
-
-			<row>
-			  <entry>20</entry> 
-
-			  <entry>
-			    
-			    <simpara>A heavy weight check, called
-			    infrequently, which may impact system or
-			    service performance.</simpara> 
-
-			    <simpara>Example: An internal consistency
-			    check to verify service
-			    integrity.w</simpara>
-			  </entry> 
-			</row>
-		      </tbody>
-		    </tgroup>
-		  </informaltable>
-		</listitem>
-	      </varlistentry>
-	    </variablelist>
-
-	    <para>Service must remain available during all of these
-	    operation.</para>
-	    
-	    <para>All other numbers are reserved.</para>
-
-	    <para> It is recommended that if a requested level is not
-	    implemented, the RA should perform the next lower level
-	    supported.</para>
-
-	  </section>
-
-	</section>
-
-      </section>
-
-      <section>
-	<title>Exit status codes</title>
-
-	<para>These exit status codes are the ones documented in the
-	LSB 1.1.0 specification, with additional explanations of how
-	they shall be used by RAs. In general, all non-zero status
-	codes shall indicate failure in accordance to the best current
-	practices.
-	</para>
-
-	<section>
-	  <title>All operations but "status"</title>
-	  <informaltable>
-	    <tgroup cols="2">
-	      <tbody>
-		<row>
-		  <entry>0</entry> 
-		  
-		  <entry>No error, action succeeded completely
-		  </entry>
-		</row>
-		
-		<row>
-		  <entry>1</entry> 
-		  
-		  <entry>generic or unspecified error (current
-		  practice)</entry>
-			    
-		</row>
-		<row>
-		  <entry>2</entry> 
-		  
-		  <entry>invalid or excess argument(s) 
-		    <simpara>Likely error
-		      code for validate-all, if the instance parameters do
-		      not validate. Any other action is free to also
-		      return this exit status code for this case.</simpara>
-		  </entry>
-			    
-		</row>
-
-		<row>
-		  <entry>3</entry> 
-		  
-		  <entry>unimplemented feature (for example, "reload")</entry>
-			    
-		</row>
-		<row>
-		  <entry>4</entry> 
-		  
-		  <entry>user had insufficient privilege</entry>
-			    
-		</row>
-		<row>
-		  <entry>5</entry> 
-		  
-		  <entry>program is not installed</entry>
-			    
-		</row>
-
-		<row>
-		  <entry>6</entry> 
-		  
-		  <entry>program is not configured</entry>
-			    
-		</row>
-		
-		<row>
-		  <entry>7</entry> 
-		  
-		  <entry>program is not running
-
-		    <simpara> Note: This is not the error code to be
-		    returned by a successful "stop" operation. A
-		    successful "stop" operation shall return
-		    0.</simpara>
-		  </entry>
-			    
-		</row>
-		<row>
-		  <entry>8-99</entry> 
-		  
-		  <entry>reserved for future LSB use</entry>
-			    
-		</row>
-		<row>
-		  <entry>100-149</entry> 
-		  
-		  <entry>reserved for distribution use</entry>
-			    
-		</row>
-		<row>
-		  <entry>150-199</entry> 
-		  
-		  <entry>reserved for application use</entry>
-			    
-		</row>
-		<row>
-		  <entry>200-254</entry> 
-		  
-		  <entry>reserved</entry>
-			    
-		</row>
-	      </tbody>
-	    </tgroup>
-	  </informaltable>
-	  
-	</section>
-
-	<section>
-	  <title>Exit status codes for "status"</title>
-	  
-	  <para>That the LSB has chosen to deviate from the set of
-	  default exit status codes for the "status" operation is
-	  unfortunate, but this specification follows this path to
-	  stay close to the LSB specification.
-	  </para>
-
-	  <para>However, a minor deviation from the values given in
-	  the LSB specification was made for the values "1" and
-	  "2". The existence of a pid file or lock file does not
-	  convey any meaning for a RA; these values have been
-	  redefined, but still imply errors.</para>
-	  
-	  <informaltable>
-	    <tgroup cols="2">
-	      <tbody>
-		<row>
-		  <entry>0</entry> 
-		  
-		  <entry>program is running or service is OK
-		  </entry>
-		</row>
-		
-		<row>
-		  <entry>1</entry> 
-		  
-		  <entry>program is dead, hung or crashed. (Generic
-		  error)</entry>
-			    
-		</row>
-		<row>
-		  <entry>2</entry> 
-		  
-		  <entry>invalid or excess argument(s) 
-		  </entry>
-			    
-		</row>
-
-		<row>
-		  <entry>3</entry> 
-		  
-		  <entry>program is not running 
-
-		  <simpara>Note: This exit code shall be returned also
-		  for cleanly inactive resource
-		  instances.</simpara></entry>
-			    
-		</row>
-		<row>
-		  <entry>4</entry> 
-		  
-		  <entry>program or service status is unknown</entry>
-			    
-		</row>
-		<row>
-		  <entry>5-99</entry> 
-		  
-		  <entry>reserved for future LSB use</entry>
-			    
-		</row>
-		<row>
-		  <entry>100-149</entry> 
-		  
-		  <entry>reserved for distribution use</entry>
-			    
-		</row>
-		<row>
-		  <entry>150-199</entry> 
-		  
-		  <entry>reserved for application use</entry>
-			    
-		</row>
-		<row>
-		  <entry>200-254</entry> 
-		  
-		  <entry>reserved</entry>
-			    
-		</row>
-	      </tbody>
-	    </tgroup>
-	  </informaltable>
-	</section>
-
-      </section>
-      
-    </section>
-
-    <section>
-      <title>Relation to the LSB</title>
-      
-      <para>It is required that the current LSB spec is fully
-      supported by the system.</para>
-
-      <para>The API tries to make it possible to have RA function both
-      as a normal LSB init script and a cluster-aware RA, but this is
-      not required functionality.  The RAs could however use the
-      helper functions defined for LSB init scripts.
-      </para>
-
-    </section>
-
-    <section>
-      <title>RA meta data</title>
-
-      <section>
-	<title>Format</title>
-	
-	<para>The API has the following requirements which are not
-	fulfilled by the LSB way of embedding meta data into the
-	beginning of the init scripts:
-
-
-	  <itemizedlist>
-	    <listitem><simpara>Independent of the language the RA is
-	    actually written in,</simpara>
-	    </listitem>
-	    
-	    <listitem><simpara>Extensible,</simpara></listitem>
-
-	    <listitem><simpara>Structured,</simpara></listitem>
-
-	    <listitem><simpara>Easy to parse from a variety of
-	    languages.</simpara></listitem> 
-
-	  </itemizedlist></para>
-
-	<para> This is why the API uses simple XML to describe the RA
-	meta data. The DTD for this API can be found at
-	http://www.opencf.org/standards/ra-api-1.dtd.</para>
-
-      </section>
-
-      <section>
-	<title>Semantics</title>
-	
-	<para>An example of a valid meta data output is provided in
-	  <filename>ra-metadata-example.xml</filename>.</para>
-
-      </section>
-    </section>
-
-    <appendix label="C">
-      <title>To-do list</title>
-      
-      <para>Move the terminology definitions out into a separate
-      document common to all OCF work.
-      </para>
-
-      <para>An interface where the RA asynchronously informs the RM of
-      failures is planned but not defined yet.</para>
-
-    </appendix>
-      
-
-    <ackno></ackno>
-    <appendix label="D">
-      <title>Contributors</title>
-
-      <simplelist>
-	<member>James Bottomley
-	  <email>James.Bottomley@steeleye.com</email></member>
-	
-	<member>Greg Freemyer
-	  <email>freemyer@NorcrossGroup.com</email></member>
-
-	<member>Simon Horman
-	  <email>horms@verge.net.au</email></member>
-     
-	<member>Ragnar Kjørstad
-	  <email>linux-ha@ragnark.vestdata.no</email></member>
-
-	<member>Lars Marowsky-Brée
-	  <email>lmb@suse.de</email></member>
-
-	<member>Alan Robertson
-	  <email>alanr@unix.sh</email></member>
-
-	<member>Yixiong Zou
-	  <email>yixiong.zou@intel.com</email></member>
-      </simplelist>
-    
-    </appendix>
-
-    <appendix label="E">
-      <title>Change Log</title>
-      <para></para>
-    </appendix>
-    
-
-
-
-
-
-
-</article>
\ No newline at end of file