Update for Danube

JIRA: COPPER-1

Updated several files for continuity in capitalization
and punctuation. Updated release notes. Updated or removed
invalid URLs.

Generated documentation locally to verify HTML output.

Change-Id: I50bc0886f502c26c8fc0539e7e8104763d1a06a2
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>

11 files changed, 109 insertions, 106 deletions

diff --git a/docs/design/architecture.rst b/docs/design/architecture.rst
index 9d9d3c3..02d8335 100644
--- a/docs/design/architecture.rst
+++ b/docs/design/architecture.rst
@@ -1,7 +1,7 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
 Architecture
 ============
diff --git a/docs/design/definitions.rst b/docs/design/definitions.rst
index 6c0175d..5552696 100644
--- a/docs/design/definitions.rst
+++ b/docs/design/definitions.rst
@@ -1,7 +1,7 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
 Definitions
 ===========
@@ -41,3 +41,6 @@ Abbreviations
 
    * - VNF
      - Virtual Network Function
+
+   * - NFVI
+     - Network Function Virtualization Infrastructure
diff --git a/docs/design/index.rst b/docs/design/index.rst
index df46a02..b1bc74b 100644
--- a/docs/design/index.rst
+++ b/docs/design/index.rst
@@ -1,7 +1,7 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
 ********************
 OPNFV Copper Project
diff --git a/docs/design/introduction.rst b/docs/design/introduction.rst
index e4d273b..cc2ceee 100644
--- a/docs/design/introduction.rst
+++ b/docs/design/introduction.rst
@@ -1,15 +1,15 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
 Introduction
 ============
 
 ..
- This work is licensed under a Creative Commons Attribution 3.0 Unported License.
+ This work is licensed under a Creative Commons Attribution 4.0 Unported License.
 
- http://creativecommons.org/licenses/by/3.0/legalcode
+ http://creativecommons.org/licenses/by/4.0
 
 .. NOTE::
    This is the working documentation for the Copper project.
@@ -18,8 +18,8 @@ The `OPNFV Copper <https://wiki.opnfv.org/copper>`_ project aims to help ensure
 that virtualized infrastructure and application deployments comply with goals of
 the NFV service provider or the VNF designer/user.
 
-This is the second ("Colorado") release of the Copper project. The documenation
-provided here focuses on the overall goals of the Copper project, and the
+This is the third ("Danube") release of the Copper project. The documentation
+provided here focuses on the overall goals of the Copper project and the
 specific features supported in the Colorado release.
 
 Overall Goals for Configuration Policy
@@ -36,7 +36,7 @@ in specific terms or more abstractly, but at the highest level they express:
   * what I don't want
 
 Using road-based transportation as an analogy, some examples of this are shown
-below.
+below:
 
 .. list-table:: Configuration Intent Example
    :widths: 10 45 45
@@ -77,7 +77,7 @@ Examples of such translation are:
    * - network security
      - firewall, DPI, private subnets
    * - compute/storage security
-     - vulerability monitoring, resource access controls
+     - vulnerability monitoring, resource access controls
    * - high availability
      - clustering, auto-scaling, anti-affinity, live migration
    * - disaster recovery
@@ -89,11 +89,11 @@ Examples of such translation are:
    * - resource reclamation
      - low-usage monitoring
 
-Although such intent to capability translation is conceptually useful, it is
+Although such intent-to-capability translation is conceptually useful, it is
 unclear how it can address the variety of aspects that may affect the choice of
 an applicable configuration capability.
 
 For that reason, the Copper project will initially focus on more specific
 configuration requirements as fulfilled by specific configuration capabilities,
-and how those requirements and capabilities are expressed in VNF and service
-design and packaging, or as generic poicies for the NFVI.
+as well as how those requirements and capabilities are expressed in VNF and service
+design and packaging or as generic policies for the NFV Infrastructure.
diff --git a/docs/design/requirements.rst b/docs/design/requirements.rst
index 7940cda..87894cf 100644
--- a/docs/design/requirements.rst
+++ b/docs/design/requirements.rst
@@ -1,7 +1,7 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
 Requirements
 ============
@@ -22,10 +22,8 @@ include multiple ways in which resource requirements can be expressed and fulfil
 
   * OpenStack Nova
 
-    * the `image <http://docs.openstack.org/openstack-ops/content/user_facing_images.html>`_ feature, enabling "VM templates" to be defined for NFs,
-      and referenced by name as a specific NF version to be used
-    * the `flavor <http://docs.openstack.org/openstack-ops/content/flavors.html>`_ feature, addressing basic compute and
-      storage requirements, with extensibility for custom attributes
+    * the Image feature, enabling "VM templates" to be defined for NFs and referenced by name as a specific NF version to be used
+    * the Flavor feature, addressing basic compute and storage requirements, with extensibility for custom attributes
 
   * OpenStack Heat
 
@@ -44,10 +42,8 @@ include multiple ways in which resource requirements can be expressed and fulfil
       * orchestration service user management (requires
         `Keystone <http://docs.openstack.org/developer/keystone/>`_)
       * shared storage (requires `Manila <https://wiki.openstack.org/wiki/Manila>`_)
-      * load balancing (requires Neutron
-        `LBaaS <http://docs.openstack.org/admin-guide-cloud/content/section_lbaas-overview.html>`_)
-      * firewalls (requires Neutron
-        `FWaaS <http://docs.openstack.org/admin-guide-cloud/content/install_neutron-fwaas-agent.html>`_)
+      * load balancing (requires `Neutron LBaaS <http://docs.openstack.org/admin-guide/networking.html>`_)
+      * firewalls (requires `Neutron FWaaS <http://docs.openstack.org/admin-guide/networking.html>`_)
       * various Neutron-based network and security configuration items
       * Nova flavors
       * Nova server attributes including access control
@@ -58,19 +54,19 @@ include multiple ways in which resource requirements can be expressed and fulfil
       * "multi-tenant cloud messaging and notification service" (requires
         `Zaqar <http://docs.openstack.org/developer/zaqar/>`_)
 
-  * OpenStack `Group-Based Policy <https://wiki.openstack.org/wiki/GroupBasedPolicy>`_
+  * `OpenStack Group-Based Policy <https://wiki.openstack.org/wiki/GroupBasedPolicy>`_
 
     * API-based grouping of endpoints with associated contractual expectations for data flow processing and service chaining
 
-  * OpenStack `Tacker <https://wiki.openstack.org/wiki/Tacker>`_
+  * `OpenStack Tacker <https://wiki.openstack.org/wiki/Tacker>`_
 
     * "a fully functional ETSI MANO based general purpose NFV Orchestrator and VNF Manager for OpenStack"
 
-  * OpenDaylight `Group-Based Policy <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`_
+  * `OpenDaylight Group-Based Policy <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`_
 
     * model-based grouping of endpoints with associated contractual expectations for data flow processing
 
-  * OpenDaylight `Service Function Chaining (SFC) <https://wiki.opendaylight.org/view/Service_Function_Chaining:Main>`_
+  * `OpenDaylight Service Function Chaining (SFC) <https://wiki.opendaylight.org/view/Service_Function_Chaining:Main>`_
 
     * model-based management of "service chains" and the infrastucture that enables them
 
@@ -113,17 +109,13 @@ high-level required capabilities include:
 Upstream projects already include multiple ways in which configuration conditions
 can be monitored and responded to:
 
-  * OpenStack `Congress <https://wiki.openstack.org/wiki/Congress>`_ provides a
+  * OpenStack `Congress <http://docs.openstack.org/developer/congress/index.html>`_ provides a
     table-based mechanism for state monitoring and proactive/reactive policy
     enforcement, including data obtained from internal databases of OpenStack
     core and optional services. The Congress design approach is also extensible
     to other VIMs (e.g. SDNCs) through development of data source drivers for
-    the new monitored state information. See
-    `Stackforge Congress Data Source Translators <https://github.com/stackforge/congress/tree/master/congress/datasources>`_,
-    `congress.readthedocs.org <http://congress.readthedocs.org/en/latest/cloudservices.html#drivers>`_,
-    and the `Congress specs <https://github.com/stackforge/congress-specs>`_ for
-    more info.
-  * OpenStack `Ceilometer <https://wiki.openstack.org/wiki/Ceilometer>`_
+    the new monitored state information.
+  * OpenStack `Aodh <https://wiki.openstack.org/wiki/Telemetry#Aodh>`_
     provides means to trigger alarms upon a wide variety of conditions derived
     from its monitored OpenStack analytics.
   * `Nagios <https://www.nagios.org/#/>`_ "offers complete monitoring and alerting for servers, switches, applications, and services".
diff --git a/docs/design/usecases.rst b/docs/design/usecases.rst
index 891539c..431590d 100644
--- a/docs/design/usecases.rst
+++ b/docs/design/usecases.rst
@@ -1,12 +1,12 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
 Use Cases
 =========
 
-Implemented as of this release
+Implemented in Current Release
 ------------------------------
 
 Network Bridging
@@ -18,16 +18,14 @@ network.
 
 An example implementation is shown in the Congress use case test "Network
 Bridging" (bridging.sh) in the Copper repo under the tests folder. This test:
-  * Identifies VMs with connected to Service Provider defined networks via
-          floating IPs.
-  * Identifies VMs that are connected to two such networks with different
-    security levels.
-  * For VMs that are thus connected, identifies those that are not owned
-    by the SP.
-  * Reactively enforces the network bridging rule by pausing VMs found to be in
-    violation of the policy.
+
+  * Identifies VMs that are connected to Service Provider (SP) defined networks via floating IPs
+  * Identifies VMs that are connected to two such networks with different security levels
+  * For VMs that are thus connected, identifies those that are not owned by the Service Provider
+  * Reactively enforces the network bridging rule by pausing VMs found to be in violation of the policy
 
 Note the assumptions related to the following example:
+
   * "SP" is the service provider tenant, and only the SP can create tenants
 
 As implemented through OpenStack Congress:
@@ -63,17 +61,14 @@ DMZ Deployment
 ..............
 
 As a service provider, I need to ensure that applications which have not been
-designed for exposure in a DMZ zone, are not attached to DMZ networks.
+designed for exposure in a DMZ zone are not attached to DMZ networks.
 
 An example implementation is shown in the Congress use case test "DMZ Placement"
 (dmz.sh) in the Copper repo under the tests folder. This test:
-  * Identifies VMs connected to a DMZ (currently identified through a
-    specifically-named security group)
-  * Identifes VMs connected to a DMZ, which are by policy not allowed to be
-    (currently implemented through an image tag intended to identify images
-    that are "authorized" i.e. tested and secure, to be DMZ-connected)
-  * Reactively enforces the dmz placement rule by pausing VMs found to be in
-    violation of the policy.
+
+  * Identifies VMs connected to a DMZ (currently identified through a specifically-named security group)
+  * Identifies VMs connected to a DMZ, which are by policy not allowed to be (currently implemented through an image tag intended to identify images that are "authorized" i.e. tested and secure, to be DMZ-connected)
+  * Reactively enforces the dmz placement rule by pausing VMs found to be in violation of the policy.
 
 As implemented through OpenStack Congress:
 
@@ -103,10 +98,11 @@ or reactive policy enforcement.
 
 An example implementation is shown in the Congress use case test "SMTP Ingress"
 (smtp_ingress.sh) in the Copper repo under the tests folder. This test:
+
   * Detects that a VM is associated with a security group that allows SMTP
     ingress (TCP port 25)
   * Adds a policy table row entry for the VM, which can be later investigated
-    for appropriate use of the security group, etc
+    for appropriate use of the security group
 
 As implemented through OpenStack Congress:
 
@@ -125,12 +121,12 @@ As implemented through OpenStack Congress:
 Reserved Resources
 ..................
 
-As an NFVI provider, I need to ensure that my admins do not inadvertently
+As an NFV Infrastructure provider, I need to ensure that my admins do not inadvertently
 enable VMs to connect to reserved subnets.
 
-An example implementation is shown in the Congress use case test "Reserved
-Subnet" (reserved_subnet.sh) in the Copper repo under the tests folder. This
-test:
+An example implementation is shown in the Congress use case test "Reserved Subnet"
+(reserved_subnet.sh) in the Copper repo under the tests folder. This test:
+
   * Detects that a subnet has been created in a reserved range
   * Reactively deletes the subnet
 
@@ -145,7 +141,7 @@ As implemented through OpenStack Congress:
    reserved_subnet_error(x)
 
 
-For further analysis and implementation
+For Further Analysis and Implementation
 ---------------------------------------
 
 Affinity
@@ -187,10 +183,10 @@ Anti-Affinity
 .............
 
 Ensures that the VM instance is launched "with anti-affinity to" specific resources,
-e.g. outside a compute or storage cluster, or geographic location. Examples
-include: "Different Host Filter", i.e. ensures that the VM instance is launched
-on a different compute node from a given set of instances, as defined in a
-scheduler hint list.
+e.g. outside a compute or storage cluster, or geographic location.
+Examples include: "Different Host Filter", i.e. ensures that the VM instance is
+launched on a different compute node from a given set of instances, as defined
+in a scheduler hint list.
 
 As implemented by OpenStack Heat using scheduler hints:
 
@@ -230,8 +226,7 @@ As implemented by OpenStack Heat using scheduler hints:
 Network Access Control
 ......................
 
-Networks connected to VMs must be public, or owned by someone in the VM owner's
-group.
+Networks connected to VMs must be public or owned by someone in the VM owner's group.
 
 This use case captures the intent of the following sub-use-cases:
 
@@ -295,9 +290,8 @@ As implemented through OpenStack Congress:
 Resource Reclamation
 ....................
 
-As a service provider or tenant, I need to be informed of VMs that are
-under-utilized so that I can reclaim the VI resources. (example from
-`RuleYourCloud blog <http://ruleyourcloud.com/2015/03/12/scaling-up-congress.html>`_)
+As a service provider or tenant, I need to be informed of VMs that are under-utilized
+so that I can reclaim the VI resources. (example from `RuleYourCloud blog <http://ruleyourcloud.com/2015/03/12/scaling-up-congress.html>`_)
 
 As implemented through OpenStack Congress:
 
@@ -317,8 +311,8 @@ As implemented through OpenStack Congress:
 Resource Use Limits
 ...................
 
-As a tenant or service provider, I need to be automatically terminate an
-instance that has run for a pre-agreed maximum duration.
+As a tenant or service provider, I need to be automatically terminate an instance
+that has run for a pre-agreed maximum duration.
 
 As implemented through OpenStack Congress:
 
@@ -334,4 +328,3 @@ As implemented through OpenStack Congress:
   reclaim_server(vm),
   nova:servers(vm, vm_name, user_id),
   keystone:users(user_id, email)
-
diff --git a/docs/installationprocedure/feature.configuration.rst b/docs/installationprocedure/feature.configuration.rst
index 1e059ef..54eab4b 100644
--- a/docs/installationprocedure/feature.configuration.rst
+++ b/docs/installationprocedure/feature.configuration.rst
@@ -1,32 +1,33 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
-Copper configuration
+Copper Configuration
 ====================
 This release includes installer support for the OpenStack Congress service under
 JOID and Apex installers. Congress is installed by default for all JOID and Apex
 scenarios. Support for other OPNFV installer deployed environments is planned
 for the next release.
 
-Pre-configuration activities
+Pre-configuration Activities
 ----------------------------
 None required.
 
-Hardware configuration
+Hardware Configuration
 ----------------------
 There is no specific hardware configuration required for the Copper project.
 
-Feature configuration
+Feature Configuration
 ---------------------
 
-OPNFV installer support
+OPNFV Installer Support
 .......................
 
 The Congress service is automatically configured as required by the JOID and
 Apex installers, including creation of datasources per the installed datasource
 drivers. This release includes default support for the following datasource drivers:
+
   * nova
   * neutronv2
   * ceilometer
@@ -41,23 +42,25 @@ future maintenance.
 Other project installer support (e.g. Doctor) may install additional datasource
 drivers once Congress is installed.
 
-Manual installation
+Manual Installation
 ...................
 
 NOTE: This section describes a manual install procedure that had been tested
-under the JOID and Apex base installs, prior to the integration of native
+under the JOID and Apex base installs prior to the integration of native
 installer support through JuJu (JOID) and Puppet (Apex). This procedure is being
 maintained as a basis for additional installer support in future releases.
-However since Congress is pre-installed for JOID and Apex, this procedure is not
+However, since Congress is pre-installed for JOID and Apex, this procedure is not
 necessary and not recommended for use if Congress is already installed.
 
 Copper provides a set of bash scripts to automatically install Congress based
 upon a JOID or Apex install which does not already have Congress installed.
 These scripts are in the Copper repo at:
+
   * components/congress/install/bash/install_congress_1.sh
   * components/congress/install/bash/install_congress_2.sh
 
 Prerequisites to using these scripts:
+
   * OPFNV installed via JOID or Apex
   * For Apex installs, on the jumphost, ssh to the undercloud VM and "su stack".
   * For JOID installs, admin-openrc.sh saved from Horizon to ~/admin-openrc.sh
@@ -74,6 +77,6 @@ specifying the branch identifier to use for OpenStack.
    wget https://git.opnfv.org/cgit/copper/plain/components/congress/install/bash/install_congress_2.sh
    bash install_congress_1.sh [openstack-branch]
 
-Copper post configuration procedures
+Copper Post Configuration Procedures
 ------------------------------------
 No configuration procedures are required beyond the basic install procedure.
diff --git a/docs/installationprocedure/installation.instruction.rst b/docs/installationprocedure/installation.instruction.rst
index c8d7ad8..da3918e 100644
--- a/docs/installationprocedure/installation.instruction.rst
+++ b/docs/installationprocedure/installation.instruction.rst
@@ -1,20 +1,21 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
-Copper post installation procedures
+Copper Post Installation Procedures
 ===================================
 
 This section describes optional procedures for verifying that the Congress
-service is operational, and additional test tools developed for the Colorado
+service is operational as well as additional test tools developed for the Colorado
 release.
 
-Copper functional tests
+Copper Functional Tests
 -----------------------
 
 This release includes the following test cases which are integrated into OPNFV
 Functest for the JOID and Apex installers:
+
   * DMZ Placement: dmz.sh
   * SMTP Ingress: smtp_ingress.sh
   * Reserved Subnet: reserved_subnet.sh
@@ -27,26 +28,28 @@ Further description of the tests is provided on the Copper wiki at
 https://wiki.opnfv.org/display/copper/testing.
 
 
-Congress test webapp
+Congress Test Webapp
 --------------------
 
 This release also provides a webapp that can be automatically installed in a
-docker container on the jumphost. This script is in the Copper repo at:
+Docker container on the OPNFV jumphost. This script is in the Copper repo at:
+
   * components/congress/test-webapp/setup/install_congress_testserver.sh
 
-Prerequisites to using this script:
+Prerequisites for using this script:
+
   * OPFNV installed per JOID or Apex installer
   * For Apex installs, on the jumphost, ssh to the undercloud VM and "su stack"
 
 To invoke the procedure, enter the following shell commands, optionally
-specifying the branch identifier to use for Copper.
+specifying the branch identifier to use for Copper:
 
 .. code::
 
    wget https://git.opnfv.org/cgit/copper/plain/components/congress/test-webapp/setup/install_congress_testserver.sh
    bash install_congress_testserver.sh [copper-branch]
 
-Using the test webapp
+Using the Test Webapp
 .....................
 
 Browse to the webapp IP address provided at the end of the install
@@ -55,9 +58,10 @@ procedure.
 Interactive options are meant to be self-explanatory given a basic familiarity
 with the Congress service and data model.
 
-Removing the test webapp
+Removing the Test Webapp
 ........................
 
 The webapp can be removed by running this script from the Copper repo:
+
   * components/congress/test-webapp/setup/clean_congress_testserver.sh
 
diff --git a/docs/releasenotes/release.notes.rst b/docs/releasenotes/release.notes.rst
index 2fd06a4..c85a900 100644
--- a/docs/releasenotes/release.notes.rst
+++ b/docs/releasenotes/release.notes.rst
@@ -1,7 +1,7 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
 Release Notes
 =============
@@ -10,6 +10,7 @@ Copper Release 1 Scope
 ----------------------
 OPNFV Brahmaputra was the initial OPNFV release for Copper, and achieved the
 goals:
+
   * Add the OpenStack Congress service to OPNFV, through at least one installer
     project, through post-install configuration.
   * Provide basis tests scripts and tools to exercise the Congress service
@@ -26,17 +27,25 @@ OPNFV Colorado includes the additional features:
   * Congress use case tests integrated into Functest and as manual tests
   * Further enhancements of Congress test tools
 
+Copper Release 3 Scope
+----------------------
+OPNFV Danube includes the additional features:
+  * Manual tests
+
+    * Network Bridging test to detect when a VM is connected to 2 networks with different security levels and then pause that VM
+
+  * Further enhancements of Congress test scripts
+
 Limitations
 ===========
 
 The following features have not been verified as of this release:
 
   * HA deployment: Congress should be installed in OPNFV deployments in a
-    non-HA mode, including in HA deployment scenarios. Basic HA support was
-    implemented for Congress in the Mitaka release (see
-    https://review.openstack.org/#/q/topic:bp/basic-high-availability,n,z), but
+    non-HA mode, including in HA deployment scenarios. Basic HA support has been
+    implemented for Congress (see http://docs.openstack.org/developer/congress/index.html), but
     this feature has not yet been verified on the OPNFV platform.
 
-  * Horizon plugin: The Congress Horizon plugin (a "policy tab") has not been
-    deployed in OPNFV as of this release. Installing the needed Horizon plugin
-    files on the Horizon host is a future work item.
+  * Horizon plugin: The Congress OpenStack Dashboard plugin (a "Policy tab") has not been
+    deployed in OPNFV as of this release. Installing the needed Congress Dashboard plugin
+    files on the OpenStack Dashboard host is a future work item.
diff --git a/docs/userguide/feature.usage.rst b/docs/userguide/feature.usage.rst
index 8efbd94..4db4533 100644
--- a/docs/userguide/feature.usage.rst
+++ b/docs/userguide/feature.usage.rst
@@ -1,14 +1,13 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015-2016 AT&T Intellectual Property, Inc
+.. (c) 2015-2017 AT&T Intellectual Property, Inc
 
-Copper capabilities and usage
+Copper Capabilities and Usage
 =============================
-This release focused on use of the OpenStack Congress service for managing
-configuration policy. See the `Congress intro guide on readthedocs
-<http://congress.readthedocs.io/en/latest/index.html>`_ for general information
-on the capabilities and usage of Congress.
+This release focuses on use of the OpenStack Congress service for managing
+configuration policy. See the Congress `intro guide <http://docs.openstack.org/developer/congress/index.html>`_
+for general information on the capabilities and usage of Congress.
 
 Examples of Congress API usage can be found in the Copper tests as described
 on the OPNFV wiki at https://wiki.opnfv.org/display/copper/testing.
diff --git a/tests/network_bridging.sh b/tests/network_bridging.sh
index 59138e4..5b36743 100644
--- a/tests/network_bridging.sh
+++ b/tests/network_bridging.sh
@@ -17,7 +17,7 @@
 # What this is: An OpenStack Congress policy test. Sets up and validates policy
 # creation and execution for:
 # 1) Detecting that a VM is connected to two networks of different 'security
-#    levels'. 'Security levels' in this example means that the service
+#    levels.' 'Security levels' in this example means that the service
 #    provider assigns distinct sensitivity/risk to connections over those
 #    networks, e.g. a public network (e.g. DMZ) and an internal/private network 
 #    (e.g. service provider admin network
@@ -27,9 +27,9 @@
 #
 # Status: this is a work in progress, under test.
 #
-# Prequisite: 
+# Prerequisite:
 # - OpenStack Congress installed as part of an OpenStack deployment,
-#   e.g. via Devstack, or OPFNV
+#   e.g. via Devstack or OPFNV
 # - OpenStack CLI environment variables setup
 # How to use:
 #   # Create Congress policy and resources that exercise policy
@@ -135,7 +135,7 @@ until [[ $COUNTER -eq 0  || $RESULT == "Test Success!" ]]; do
   let COUNTER-=1
   sleep 5
 done
-echo "$0: $(date) smz_connected table entries present for cirros1, cirros2:" $RESULT
+echo "$0: $(date) dmz_connected table entries present for cirros1, cirros2:" $RESULT
 if [ "$RESULT" == "Test Failed!" ]; then fail; fi
 
 echo "$0: $(date) Verify cirros1 and cirros2 IDs are in the Congress policy 'test' table 'admin_connected'"