Description 
The explanation of false_easting/northing has left us often puzzled weather false_easting should be added to the existing xaxis values, or subtracted. To clarify this, I suggest the following modification to Table F.1:
false_easting
The value applied to all abscissa values in the rectangular coordinates for a map projection. This value frequently is assigned to eliminate negative numbers. Expressed in the unit of the coordinate variable identified by the standard name projection_x_coordinate. The formula to convert from a projectionaxis value without false_easting (x0) to a projectionaxis value with false_easting is (xf) is:
x0 = xf  false_easting
false_northing
The value applied to all ordinate values in the rectangular coordinates for a map projection. This value frequently is assigned to eliminate negative numbers. Expressed in the unit of the coordinate variable identified by the standard name projection_y_coordinate. The formula to convert from a projectionaxis value without false_northing (y0) to a projectionaxis value with false_northing is (yf) is then:
y0 = yf  false_northing

Description 
Section 3.3. of the CF convention states:
"Some standard names (e.g. region and area_type) are used to indicate quantities which are permitted to take only certain standard values. This is indicated in the definition of the quantity in the standard name table, accompanied by a list or a link to a list of the permitted values."
but there is no corresponding statement in the conformance document. I therefore propose to add the following to section 3.3 of the CF Conformance document:
"If a variable has a standard_name of region or area_type, it must have
value(s) from the permitted list."

Description 
1. Title
Clarifying the role of attributes on boundary variables.
2. Moderator
TBC (any offer will be gladly accepted).
3. Requirement
To disallow inconsistencies between particular attributes of a
boundary variable and its associated coordinate or auxiliary
coordinate variable.
For example, it is currently possible for a boundary variable to
have a different standard_name attribute to its associated
coordinate or auxiliary coordinate variable. This would be
unsatisfactory because the user of the data cannot know which of
the possibilities is correct.
It is proposed that if a boundary variable has attributes which
determine the coordinate type (units, standard_name, axis and
positive) or those which affect the interpretation of the boundary
variable array values (units, calendar, leap_month, leap_year and
month_lengths) then they must always agree exactly with the same
attributes of its associated coordinate or auxiliary coordinate
variable. In addition, it is recommended that these attributes are
not provided to a boundary variable since they are already
inherited implicitly.
No restriction is made on any other boundary variable attributes.
This does not affect datasets encoded with previous versions of CF
4. Initial Statement of Technical Proposal
The following changes should be made to section 7.1. Cell Boundaries
(additions marked by TEXT, deletions by TEXT):
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). and providing no attributes
is always acceptable. 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 or auxiliary coordinate variable. To avoid
duplication, however, it is recommended that the attributes units,
standard_name, axis, positive, calendar, leap_month,
leap_year and month_lengths are not provided to a boundary
variable.
In section 7.1 Cell Boundaries of the conformance document
(additions marked by TEXT, deletions by TEXT):
 Requirements:
 The type of the bounds attribute is a string whose value is a
single variable name. The specified variable must exist in the
file.
 A boundary variable must have the same dimensions as its
associated variable, plus have a trailing dimension (CDL order)
for the maximum number of vertices in a cell.
 A boundary variable must be a numeric data type.
 If a boundary variable has
units or standard_name
attributes, they must agree with those of its associated
variable. units, standard_name, axis, positive,
calendar, leap_month, leap_year and month_lengths
attributes, they must agree exactly with those of its associated
variable.
 Recommendations:
 The points specified by a coordinate or auxiliary coordinate
variable should lie within, or on the boundary, of the cells
specified by the associated boundary variable.
 Boundary variables should not have the
_FillValue or
missing_value _FillValue, missing_value, units,
standard_name, axis, positive, calendar, leap_month,
leap_year or month_lengths attributes.
5. Benefits
It would be disallowed to encode typedetermining attributes
(units, calendar, standard_name, axis and positive) or array
value interpretation attirbutes (units, calendar, leap_month,
leap_year and month_lengths) on a boundary variable if they conflict
with the associated coordinate or auxiliary coordinate variable.
6. Status Quo
Attributes on a boundary variable may conflict with the associated
coordinate or auxiliary coordinate variable, and this is not always
checked by the CF checker.
This proposal does not affect datasets encoded under previous
versions of CF, other than via the potential for extra warnings
being raised by the CF checker.
David Hassell
