Copy edited version.

diff --git a/README.markdown b/README.markdown
index 144276ba761dabc2d587059f81ed2843044588a2..7f92339d4e408f38f733f20f88afe48dc83c15f3 100644 (file)
--- a/README.markdown
+++ b/README.markdown
@@ -26,29 +26,29 @@ The Firewall module lets you manage firewall rules with Puppet.
 
 ##Module Description
 
-PuppetLabs' Firewall module introduces the resource `firewall`, which is used to manage and configure firewall rules from within the Puppet DSL. This module offers support for iptables and ip6tables. The module also introduces the resource `firewallchain`, which allows you to manage chains or firewall lists and ebtables for bridging support. At the moment, only iptables and ip6tables chains are supported.
+PuppetLabs' Firewall module introduces the `firewall` resource, which is used to manage and configure firewall rules from within the Puppet DSL. This module offers support for iptables and ip6tables. The module also introduces the `firewallchain` resource, which allows you to manage chains or firewall lists and ebtables for bridging support. At the moment, only iptables and ip6tables chains are supported.
 
-The Firewall module acts on your running firewall, making immediate changes as the catalog executes. Defining default pre and post rules allows you to provide global defaults for your hosts before and after any custom rules; defining pre and post rules is also necessary to help you avoid locking yourself out of your own boxes when Puppet runs. 
+The Firewall module acts on your running firewall, making immediate changes as the catalog executes. Defining default pre and post rules allows you to provide global defaults for your hosts before and after any custom rules. Defining `pre` and `post` rules is also necessary to help you avoid locking yourself out of your own boxes when Puppet runs. 
 
 ##Setup
 
 ###What Firewall Affects
 
 * Every node running a firewall
-* System's firewall settings
+* FIrewall Settings in Your System
 * Connection settings for managed nodes
 * Unmanaged resources (get purged)
 
 
 ###Setup Requirements
 
-Firewall uses Ruby-based providers, so you must have [pluginsync enabled](http://docs.puppetlabs.com/guides/plugins_in_modules.html#enabling-pluginsync).
+Firewall uses Ruby-based providers, so you must enable [pluginsync enabled](http://docs.puppetlabs.com/guides/plugins_in_modules.html#enabling-pluginsync).
 
 ###Beginning with Firewall
 
 In the following two sections, you create new classes and then create firewall rules related to those classes. These steps are optional, but provide a framework for firewall rules, which is helpful if you’re just starting to create them. 
 
-If you already have rules in place, then you don’t need to do these two sections. However, be aware of the ordering of your firewall rules. The module will dynamically apply rules in the order they appear in the catalog, meaning a deny rule could be applied before the allow rules. This might mean it hasn’t established some of the important connections, such as the connection to the Puppet master. 
+If you already have rules in place, then you don’t need to do these two sections. However, be aware of the ordering of your firewall rules. The module will dynamically apply rules in the order they appear in the catalog, meaning a deny rule could be applied before the allow rules. This might mean the mdule hasn’t established some of the important connections, such as the connection to the Puppet master. 
 
 The following steps are designed to ensure that you keep your SSH and other connections, primarily your connection to your Puppet master. If you create the `pre` and `post` classes described in the first section, then you also need to create the rules described in the second section.
 
@@ -56,51 +56,53 @@ The following steps are designed to ensure that you keep your SSH and other conn
 
 This approach employs a whitelist setup, so you can define what rules you want and everything else is ignored rather than removed.
 
-The code in this section does the following: The `require` parameter in `Firewall {}` ensures `my_fw::pre` is run before any other rules.  In the `my_fw::post` class declaration, the `before` parameter ensures `my_fw::post` is run after any other rules. So the run order is:
+The code in this section does the following: 
+* The `require` parameter in `Firewall {}` ensures `my_fw::pre` is run before any other rules.  
+* In the `my_fw::post` class declaration, the `before` parameter ensures `my_fw::post` is run after any other rules. 
+
+Therefore, the run order is:
 
 * The rules in `my_fw::pre`
 * Your rules (defined in code)
 * The rules in `my_fw::post`
 
-The rules in the `pre` and `post` classes are fairly general. The rules you define in your manifests are likely specific to the applications you run. 
-
-These two classes ensure that you retain connectivity, and that you drop unmatched packets appropriately.
+The rules in the `pre` and `post` classes are fairly general. These two classes ensure that you retain connectivity, and that you drop unmatched packets appropriately. The rules you define in your manifests are likely specific to the applications you run. 
 
 1. Add the `pre` class to `my_fw/manifests/pre.pp`. `pre.pp` should contain any default rules to be applied first. The rules in this class should be added in the order you want them to run.
 
-       class my_fw::pre {
-           Firewall {
-                require => undef,
-           }
-
-           # Default firewall rules
-           firewall { '000 accept all icmp':
-                proto   => 'icmp',
-                action  => 'accept',
-           }->
-           firewall { '001 accept all to lo interface':
-                proto   => 'all',
-                iniface => 'lo',
-                action  => 'accept',
-           }->
-           firewall { '002 accept related established rules':
-                proto   => 'all',
-                ctstate => ['RELATED', 'ESTABLISHED'],
-                action  => 'accept',
-           }
-       }
+    class my_fw::pre {
+      Firewall {
+        require => undef,
+      }
+
+      # Default firewall rules
+      firewall { '000 accept all icmp':
+        proto   => 'icmp',
+        action  => 'accept',
+      }->
+      firewall { '001 accept all to lo interface':
+        proto   => 'all',
+        iniface => 'lo',
+        action  => 'accept',
+      }->
+      firewall { '002 accept related established rules':
+        proto   => 'all',
+        ctstate => ['RELATED', 'ESTABLISHED'],
+        action  => 'accept',
+      }
+    }
 
 The rules in `pre` should allow basic networking (such as ICMP and TCP), and ensure that existing connections are not closed.
 
 2. Add the `post` class to `my_fw/manifests/post.pp` and include any default rules to be applied last.
 
-       class my_fw::post {
-           firewall { '999 drop all':
-                proto   => 'all',
-                action  => 'drop',
-                before  => undef,
-          }
-        }
+    class my_fw::post {
+      firewall { '999 drop all':
+        proto   => 'all',
+        action  => 'drop',
+        before  => undef,
+      }
+    }
 
 ####Create Firewall Rules
 
@@ -109,32 +111,33 @@ The rules you create here are helpful if you don’t have any existing rules; th
 Rules are persisted automatically between reboots, although there are known issues with ip6tables on older Debian/Ubuntu distributions. There are also known issues with ebtables.
 
 1. In `site.pp` or another top-scope file, add the following code to set up a metatype to purge unmanaged firewall resources. This will clear any existing rules and make sure that only rules defined in Puppet exist on the machine. 
-**Note** - The below only purges IPv4 rules. 
 
-       resources { "firewall":
-           purge => true
-       }
+**Note** - This only purges IPv4 rules. 
+
+    resources { "firewall":
+      purge => true
+    }
 
 2.  Use the following code to set up the default parameters for all of the firewall rules you will establish later. These defaults will ensure that the `pre` and `post` classes are run in the correct order to avoid locking you out of your box during the first Puppet run.
 
-       Firewall {
-           before  => Class['my_fw::post'],
-           require => Class['my_fw::pre'],
-       }
+    Firewall {
+      before  => Class['my_fw::post'],
+      require => Class['my_fw::pre'],
+    }
 
 3. Then, declare the `my_fw::pre` and `my_fw::post` classes to satisfy dependencies. You can declare these classes using an **External Node Classifier** or the following code:
 
-       class { ['my_fw::pre', 'my_fw::post']: }
+    class { ['my_fw::pre', 'my_fw::post']: }
 
 4. Include the `firewall` class to ensure the correct packages are installed.
 
-       class { 'firewall': }
+    class { 'firewall': }
 
 ###Upgrading
 
 Use these steps if you already have a version of the Firewall module installed.
 
-####From version 0.2.0 and newer
+####From version 0.2.0 and more recent
 
 Upgrade the module with the puppet module tool as normal:
 
@@ -198,7 +201,7 @@ class profile::apache {
 
 ###Additional Uses for the Firewall Module
 
-You can apply firewall rules to specific nodes. Usually, you will want to put the firewall rule in another class and apply that class to a node. Apply a rule to a node as follows.
+You can apply firewall rules to specific nodes. Usually, you will want to put the firewall rule in another class and apply that class to a node. Apply a rule to a node as follows:
 
     node 'some.node.com' {
       firewall { '111 open port 111':