diff --git a/ch07.adoc b/ch07.adoc
index 9b7c76dd..44440b64 100644
--- a/ch07.adoc
+++ b/ch07.adoc
@@ -9,9 +9,9 @@ When gridded data does not represent the point values of a field but instead rep
 [[cell-boundaries, Section 7.1, "Cell Boundaries"]]
 === Cell Boundaries
 
-To represent cells we add the attribute **`bounds`** to the appropriate coordinate variable(s). The value of **`bounds`** is the name of the variable that contains the vertices of the cell boundaries. We refer to this type of variable as a "boundary variable." __A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable.__ The additional dimension should be the most rapidly varying one, and its size is the maximum number of cell vertices. Since a boundary variable is considered to be part of a coordinate variable's metadata, it is not necessary to provide it with attributes such as **`long_name`** and **`units`**.
+To represent cells we add the attribute **`bounds`** to the appropriate coordinate variable(s). The value of **`bounds`** is the name of the variable that contains the vertices of the cell boundaries. We refer to this type of variable as a "boundary variable." __A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable.__ The additional dimension should be the most rapidly varying one, and its size is the maximum number of cell vertices.
 
-Boundary variable attributes which determine the coordinate type (**`units`**, **`standard_name`**, **`axis`** and **`positive`**) or those which affect the interpretation of the array values (**`units`**, **`calendar`**, **`leap_month`**, **`leap_year`** and **`month_lengths`**) must always agree exactly with the same attributes of its associated coordinate, scalar coordinate or auxiliary coordinate variable. To avoid duplication, however, it is recommended that these are not provided to a boundary variable.
+Since a boundary variable is considered to be part of a coordinate variable's metadata, it is not necessary to provide it with attributes such as **`long_name`** and **`units`**.  Functional attributes which determine the coordinate type (**`units`**, **`standard_name`**, **`axis`** and **`positive`**), or those which affect the interpretation of the array values (**`units`**, **`calendar`**, **`leap_month`**, **`leap_year`** and **`month_lengths`**), should be inherited from the associated parent coordinate variable, rather than being attached to the boundary variable itself.  Duplication of such functional attributes on the boundary variable is permissible but not recommended.  When such duplicates are included, they must exactly match the parent variable attributes in both data type and value.
 
 If a parametric coordinate variable with a **`formula_terms`** attribute (section 4.3.2) also has a **`bounds`** attribute, its boundary variable must have a **`formula_terms`** attribute too. In this case the same terms would appear in both (as specified in Appendix D), since the transformation from the parametric coordinate values to physical space is realized through the same formula. For any term that depends on the vertical dimension, however, the variable names appearing in the formula terms would differ from those found in the **`formula_terms`** attribute of the coordinate variable itself because the boundary variables for formula terms are two-dimensional while the formula terms themselves are one-dimensional.