diff --git a/extensions/amp-access/amp-access.md b/extensions/amp-access/amp-access.md
index eb31def68703..15f53ec44bbc 100644
--- a/extensions/amp-access/amp-access.md
+++ b/extensions/amp-access/amp-access.md
@@ -21,7 +21,7 @@ limitations under the License.
 <table>
   <tr>
     <td class="col-fourty"><strong>Description</strong></td>
-    <td>AMP Access or “AMP paywall and subscription support” gives publishers control over which content can be accessed by a reader and with what restrictions, based on the reader’s subscription status, number of views, and other factors.</td>
+    <td>AMP Access or “AMP paywall and subscription support” gives Publishers control over which content can be accessed by a Reader and with what restrictions, based on the Reader’s subscription status, number of views, and other factors.</td>
   </tr>
   <tr>
     <td class="col-fourty"><strong>Availability</strong></td>
@@ -49,55 +49,55 @@ limitations under the License.
 
 The proposed solution gives control to the Publisher over the following decisions and flows:
  - Create and maintain users
- - Control of metering
+ - Control of metering (allow for a certain number of free views)
  - Responsibility for the login flow
  - Responsibility for authenticating the user
  - Responsibility for access rules and authorization
- - Flexibility over access parameters at a per-document level
+ - Flexibility over access parameters on a per-document basis
 
 The solution comprises the following components:
 
-1. [**AMP Reader ID**][2]: provided by AMP ecosystem, this is a unique identifier of the reader as seen by AMP.
+1. [**AMP Reader ID**][2]: provided by the AMP ecosystem, this is a unique identifier of the Reader as seen by AMP.
 2. [**Access Content Markup**][3]: authored by the Publisher, defines which parts of a document are visible in which circumstances.
 3. [**Authorization endpoint**][4]: provided by the Publisher, returns the response that explains which part of a document the Reader can consume.
 4. [**Pingback endpoint**][5]: provided by the Publisher, is used to send the “view” impression for a document.
-5. [**Login Link and Login Page**][6]: allows the publisher to authenticate the Reader and connect their identity with AMP Reader ID.
+5. [**Login Link and Login Page**][6]: allows the Publisher to authenticate the Reader and connect their identity with AMP Reader ID.
 
-Google AMP Cache returns the document to the Reader with some sections obscured using Access Content Markup. The AMP Runtime calls the Authorization endpoint and uses the response to either hide or show different sections as defined by the Access Content Markup. After the document has been shown to the Reader, AMP Runtime calls the Pingback endpoint that can be used by the Publisher to update the countdown meter.
+Google AMP Cache returns the document to the Reader with some sections obscured using Access Content Markup. The AMP Runtime calls the Authorization endpoint and uses the response to either hide or show different sections as defined by the Access Content Markup. After the document has been shown to the Reader, AMP Runtime calls the Pingback endpoint that can be used by the Publisher to update the countdown meter (number of free views used).
 
-The solution also allows the Publisher to place in the AMP document  a Login Link that launches the Login/Subscribe Page where the Publisher can authenticate the Reader and associate the Reader’s identity in their system with the AMP Reader ID.
+The solution also allows the Publisher to place in the AMP document a Login Link that launches the Login/Subscribe page where the Publisher can authenticate the Reader and associate the Reader’s identity in their system with the AMP Reader ID.
 
 In its basic form, this solution sends the complete (though obscured) document to the Reader and simply shows/hides restricted sections based on the Authorization response. However, the solution also provides the “server” option, where the restricted sections can be excluded from the initial document delivery and downloaded only after the authorization has been confirmed.
 
-Supporting AMP Access requires Publisher to implement the components described above. Access Content Markup and Authorization endpoint are required. Pingback endpoint and Login Page are optional.
+Supporting AMP Access requires that the Publisher implement the components described above. Access Content Markup and Authorization endpoint are required. Pingback endpoint and Login Page are optional.
 
 ### AMP Reader ID
 
-To assist access services and use cases, AMP Access introduces the concept of the *Reader ID*.
+To assist access services and use cases, AMP Access introduces the concept of *Reader ID*.
 
-The Reader ID is an anonymous and unique ID created by the AMP ecosystem. It is unique for each reader/publisher pair. i.e., a Reader is identified differently to two different publishers. It is a non-reversible ID. The Reader ID is included in all AMP/Publisher communications. Publishers must use the Reader ID to identify the Reader and map it to their own identity systems.
+The Reader ID is an anonymous and unique ID created by the AMP ecosystem. It is unique for each Reader/Publisher pair - a Reader is identified differently to two different Publishers. It is a non-reversible ID. The Reader ID is included in all AMP/Publisher communications. Publishers must use the Reader ID to identify the Reader and map it to their own identity systems.
 
 The Reader ID is constructed on the user device and intended to be long-lived. However, it follows the normal browser storage rules, including those for incognito windows. The intended lifecycle of a Reader ID is 1 year between uses or until the user clears their cookies. The Reader IDs are not currently shared between devices.
 
-The Reader ID is constructed similar to the mechanism used to build ExternalCID described [here](https://docs.google.com/document/d/1f7z3X2GM_ASb3ZCI_7tngglxwS6WoWi1EB3aKzdf6vo/edit#heading=h.hyyaxi8m42a).
+The Reader ID is constructed similarly to the mechanism used to build ExternalCID described [here](https://docs.google.com/document/d/1f7z3X2GM_ASb3ZCI_7tngglxwS6WoWi1EB3aKzdf6vo/edit#heading=h.hb9q0wpwwhuf). An example Reader ID is `amp-OFsqR4pPKynymPyMmplPNMvxSTsNQob3TnK-oE3nwVT0clORaZ1rkeEz8xej-vV6`.
 
 ### AMP Access and Cookies
 
-Even though some of the Publisher's own authentication cookies may be available at the time of the Authorization and Pingback requests, the cookies should only be used for internal mapping. There are no guarantees that the Publisher will be able to read or write cookies given all surfaces and platforms where an AMP document can be embedded. The Reader ID is the only identifier that is guaranteed to work.
+Even though some of the Publisher’s own authentication cookies may be available at the time of the Authorization and Pingback requests, the cookies should only be used for internal mapping. There are no guarantees that the Publisher will be able to read or write cookies given all surfaces and platforms where an AMP document can be embedded. The Reader ID is the only identifier that is guaranteed to work.
 
-This means, in particular, that features such as metering and first-click-free implementation have to rely on the AMP Reader ID and server-side storage.
+This means, in particular, that features such as metering and first-click-free have to rely on the AMP Reader ID and server-side storage.
 
 ### Access Content Markup
 
-Access Content Markup determines which sections are visible or hidden based on the authorization response returned from the Authorization endpoint. It is described via special markup attributes.
+Access Content Markup determines which sections are visible or hidden based on the Authorization response returned from the Authorization endpoint. It is described via special markup attributes.
 
 ### Authorization Endpoint
 
-Authorization is an endpoint provided by the publisher and called by AMP Runtime or Google AMP Cache. It is a credentialed CORS GET endpoint. This endpoint returns the access parameters that can be used by the Content Markup to hide or show different parts of the document.
+Authorization is an endpoint provided by the publisher and called by the AMP Runtime or Google AMP Cache. It is a credentialed CORS GET endpoint. This endpoint returns the access parameters that can be used by the Content Markup to hide or show different parts of the document.
 
 ### Pingback Endpoint
 
-Pingback is an endpoint provided by the publisher and called by AMP Runtime or Google AMP Cache. It is a credentialed CORS POST endpoint. AMP Runtime calls this endpoint automatically when the Reader has started viewing the document. This endpoint is also called after the Reader has successfully completed the Login Flow. On of the main goals of the Pingback is for the Publisher to update metering information.
+Pingback is an endpoint provided by the publisher and called by the AMP Runtime or Google AMP Cache. It is a credentialed CORS POST endpoint. AMP Runtime calls this endpoint automatically when the Reader has started viewing the document. This endpoint is also called after the Reader has successfully completed the Login Flow. On of the main goals of the Pingback is for the Publisher to update metering information.
 
 Pingback optional. It can be disabled by setting `noPingback` configuration property to `true`.
 
@@ -165,7 +165,7 @@ When configuring the URLs for various endpoints, the Publisher can use substitut
 | CANONICAL_URL     | The canonical URL of this AMP Document. |
 | DOCUMENT_REFERRER | The Referrer URL. |
 | VIEWER            | The URL of the AMP Viewer. |
-| RANDOM            | A random number. Helpful to avoid browser cache. |
+| RANDOM            | A random number. Helpful to avoid browser caching. |
 
 Here’s an example of the URL extended with Reader ID, Canonical URL, Referrer information and random cachebuster:
 ```text
@@ -225,7 +225,7 @@ Here:
  - *subscriber* is a boolean field in the authorization response returned by the Authorization endpoint. This section is hidden by default, which is optional.
  - This example elects to show full content optimistically.
 
-Here’s another example that shows the disclaimer to the reader about the state of metering:
+Here’s another example that shows the disclaimer to the Reader about the state of metering:
 ```html
 <section amp-access="views <= maxViews">
   <template amp-access-template type="amp-mustache">
@@ -291,35 +291,35 @@ The authorization response may be used by AMP Runtime and extensions for three d
  2. When evaluating `<template>` templates such as `amp-mustache`.
  3. When providing additional variables to pingback and login URLs using `AUTHDATA(field)`.
 
-Authorization endpoint is called by AMP Runtime as a credentialed CORS endpoint. As such, it must implement CORS protocol. It should use CORS Origin and source origin to restrict the access to this service as described in the [CORS Origin Security][9]. This endpoint may use publisher cookies for its needs. For instance, it can associate the binding between the Reader ID and the Publisher’s own user identity. AMP itself does not need to know about this (and prefers not to). Reader more on [AMP Reader ID][2] and [AMP Access and Cookies][11] for more detail.
+The Authorization endpoint is called by the AMP Runtime as a credentialed CORS endpoint. As such, it must implement the CORS protocol. It should use CORS Origin and source origin to restrict the access to this service as described in the [CORS Origin Security][9]. This endpoint may use Publisher cookies for its needs. For instance, it can associate the binding between the Reader ID and the Publisher’s own user identity. AMP itself does not need to know about this (and prefers not to). For more detail, see the [AMP Reader ID][2] and [AMP Access and Cookies][11] documentation.
 
-AMP Runtime (or rather browser) observes cache response headers when calling Authorization endpoint. Thus the cached responses can be reused. It may or may not be desirable. If it is not desirable, the Publisher can user the appropriate cache control headers and/or RANDOM variable substitution for the endpoint URL.
+The AMP Runtime (or rather the browser) observes cache response headers when calling the Authorization endpoint. Thus the cached responses can be reused. This may or may not be desirable. If it is not desirable, the Publisher can use the appropriate cache control headers and/or the `RANDOM` variable substitution for the endpoint URL.
 
-If Authorization request fails, AMP Runtime will fallback to the "authorizationFallbackResponse", if it's specified in the configuration. In this case the authorization flow will proceed without as normal with the value of the "authorizationFallbackResponse" property in place of the authorization response. If the "authorizationFallbackResponse" is not specified, the authorization flow will fail, in which case the `amp-access` expressions will not be evaluated and whether a section is visible or hidden will be determined by the presence of the `amp-access-hide` attribute initially provided by the document.
+If the Authorization request fails, the AMP Runtime will fallback to the "authorizationFallbackResponse", if it’s specified in the configuration. In this case the authorization flow will proceed as normal with the value of the "authorizationFallbackResponse" property in place of the authorization response. If the "authorizationFallbackResponse" is not specified, the authorization flow will fail, in which case the `amp-access` expressions will not be evaluated and whether a section is visible or hidden will be determined by the presence of the `amp-access-hide` attribute initially provided by the document.
 
-Authorization request is automatically timed out and assumed to have failed after 3 seconds.
+The Authorization request is automatically timed out and assumed to have failed after 3 seconds.
 
 AMP Runtime uses the following CSS classes during the authorization flow:
- 1. `amp-access-loading` CSS class is set on the document root when the authorization flow starts and removed when it completes or fails.
- 2. `amp-access-error` CSS class is set on the document root when the authorization flow fails.
+ 1. the `amp-access-loading` CSS class is set on the document root when the authorization flow starts and removed when it completes or fails.
+ 2. the `amp-access-error` CSS class is set on the document root when the authorization flow fails.
 
-In the *server* option, the call to Authorization endpoint is done by Google AMP Cache as a simple HTTPS endpoint. This means that the Publisher’s cookies cannot be delivered in this case.
+In the *server* option, the call to the Authorization endpoint is made by the Google AMP Cache as a simple HTTPS endpoint. This means that the Publisher’s cookies cannot be delivered in this case.
 
 ### Pingback Endpoint
 
-Pingback is configured via `pingback` property in the [AMP Access Configuration][8] section. It is a credentialed CORS POST endpoint. See [CORS Origin Security][9]” for how this request should be secured.
+Pingback is configured via the `pingback` property in the [AMP Access Configuration][8] section. It is a credentialed CORS POST endpoint. See [CORS Origin Security][9] for how this request should be secured.
 
-Pingback URL is optional. It can be disabled with `"noPingback": true` configuration.
+Pingback URL is optional. It can be disabled with `"noPingback": true`.
 
-Pingback URL can take any parameters as defined in the [Access URL Variables][7] section. For instance, it could pass AMP Reader ID and document URL. The inclusion of the `READER_ID` is required.
+Pingback URL can take any parameters as defined in the [Access URL Variables][7] section. For instance, it could pass the AMP Reader ID and document URL. The inclusion of the `READER_ID` is required.
 
-Pingback does not produce a response - any response is ignored by AMP runtime.
+Pingback does not produce a response - any response is ignored by the AMP runtime.
 
-Pingback endpoint is called when the reader has started viewing the document and after the Reader has successfully completed the Login Flow.
+The Pingback endpoint is called when the Reader has started viewing the document and after the Reader has successfully completed the Login Flow.
 
-The publisher may choose to use the pingback as:
- - One of the main purposes for pingback is to count down meter when it is used.
- - As a credentialed CORS endpoint it may contain publisher cookies. Thus it can be used to map AMP Reader ID to the Publisher’s identity.
+The publisher may choose to use the pingback:
+ - to count down the number of free views of the page
+ - to map the AMP Reader ID to the Publisher’s identity, since as a credentialed CORS endpoint, the Pingback may contain Publisher cookies
 
 The request format is:
 ```text
@@ -332,7 +332,7 @@ https://publisher.com/amp-pingback?
 
 The URL of the Login Page(s) is configured via the `login` property in the [AMP Access Configuration][8] section.
 
-The configuration can specify either a single Login URL or a map of Login URL indexed by the type of login. An example of a single Login URL:
+The configuration can specify either a single Login URL or a map of Login URLs keyed by the type of login. An example of a single Login URL:
 ```json
 {
   "login": "https://publisher.com/amp-login.html?rid={READER_ID}"
@@ -349,11 +349,9 @@ An example of multiple Login URLs:
 }
 ```
 
-The URL can take any parameters as defined in the [Access URL Variables][7] section. For instance, it could pass AMP Reader ID and document URL. `RETURN_URL` query substitution can be used to specify query parameter for return URL, e.g. `?ret=RETURN_URL`. The return URL is
-required and if the `RETURN_URL` substitution is not specified, it will be injected automatically with the default query parameter name of
-"return".
+The URL can take any parameters as defined in the [Access URL Variables][7] section. For instance, it could pass the AMP Reader ID and document URL. The `RETURN_URL` query substitution can be used to specify the query parameter for the return URL, e.g. `?ret=RETURN_URL`. The return URL is required and if the `RETURN_URL` substitution is not specified, it will be injected automatically with the default query parameter name of "return".
 
-Login Page is simply a normal Web page with no special constraints, other than it should function well as a [browser dialog](https://developer.mozilla.org/en-US/docs/Web/API/Window/open). See the [Login Flow][14] section for more details.
+Login Page is simply a normal web page with no special constraints, other than it should function well as a [browser dialog](https://developer.mozilla.org/en-US/docs/Web/API/Window/open). See the [Login Flow][14] section for more details.
 
 The request format is:
 ```text
@@ -363,37 +361,35 @@ https://publisher.com/amp-login.html?
   &return=RETURN_URL
 ```
 Notice that the “return” URL parameter is added by the AMP Runtime automatically if `RETURN_URL` substitution is not
-specified. Once Login Page completes its work, it must redirect back to the specified “Return URL” with the following format:
+specified. Once the Login Page completes its work, it must redirect back to the specified “Return URL” with the following format:
 ```text
 RETURN_URL#success=true|false
 ```
 Notice the use of a URL hash parameter “success”. The value is either “true” or “false” depending on whether the login succeeds or is abandoned. Ideally the Login Page, when possible, will send the signal in cases of both success or failure.
 
-If the `success=true` signal is returned, the AMP runtime will repeat calls to Authorization and Pingback endpoints to update the document's state and report the "view" with the new access profile.
+If the `success=true` signal is returned, the AMP Runtime will repeat calls to the Authorization and Pingback endpoints to update the document’s state and report the "view" with the new access profile.
 
 #### Login Link
 
 The Publisher may choose to place the Login Link anywhere in the content of the document.
 
-A single or multiple Login URLs are configured via “login” property in the [AMP Access Configuration][8] section.
+One or more Login URLs are configured via the “login” property in the [AMP Access Configuration][8] section.
 
-Login Link can be declared on any HTML element that allows “on” attribute, most typically it’d be an anchor or a button element.
-
-The format follows "Login URL" configuration. When a single Login URL is configured, the format is:
+The Login link can be declared on any HTML element that allows the “on” attribute. Typically this would be an anchor or a button element. When a single Login URL is configured, the format is:
 ```html
 <a on="tap:amp-access.login">Login or subscribe</a>
 ```
 
-When multiple Login URLs are configured, the format is `tap:amp-access.login-{type}`. Ex.:
+When multiple Login URLs are configured, the format is `tap:amp-access.login-{type}`. Example:
 ```html
 <a on="tap:amp-access.login-signup">Subscribe</a>
 ```
 
-AMP makes no distinction between login or subscribe. This distinction can be configured by the Publisher using multiple Login URLs/links or on the Publisher’s side.
+AMP makes no distinction between login and subscribe. This distinction can be configured by the Publisher using multiple Login URLs/links or on the Publisher’s side.
 
 ## Integration with *amp-analytics*
 
-An integration with *amp-analytics* is documented in the [amp-access-analytics.md](./amp-access-analytics.md).
+The integration with *amp-analytics* is documented in the [amp-access-analytics.md](./amp-access-analytics.md).
 
 ## CORS Origin Security
 
@@ -401,6 +397,7 @@ Authorization and Pingback endpoints are CORS endpoints and they must implement
 [AMP CORS Security Spec](https://github.com/ampproject/amphtml/blob/master/spec/amp-cors-requests.md#cors-security-in-amp).
 
 ## Metering
+
 Metering is the system where the Reader is shown premium content for free for several document views in some period. Once some quota is reached, the Reader is shown the paywall kicks in and the Reader instead is shown partial content with upsell message and signup/login link. For instance, the metering can be defined as “Reader can read 10 articles per month for free”.
 
 AMP Access provides the following facilities for implementing metered access:
@@ -409,13 +406,15 @@ AMP Access provides the following facilities for implementing metered access:
  3. Only unique documents can be counted against the quota. I.e. refreshing the same document ten times constitutes a single view. For this purpose Authorization and Pingback endpoints can inject `SOURCE_URL` or similar URL variables. See [Access URL Variables][7].
 
 ## First-Click-Free
-Google's First-click-free (or FCF) policy is described [here](https://support.google.com/news/publisher/answer/40543), with the most recent update described in more detail [here](https://googlewebmastercentral.blogspot.com/2015/09/first-click-free-update.html).
+
+Google’s First-click-free (or FCF) policy is described [here](https://support.google.com/news/publisher/answer/40543), with the most recent update described in more detail [here](https://googlewebmastercentral.blogspot.com/2015/09/first-click-free-update.html).
 
 To implement FCF, the Publisher must (1) be able to determine the referring service for each view, and (2) be able to count number of views per day for each reader.
 
 Both steps are covered by the AMP Access spec. The referrer can be injected into the Authorization and Pingback URLs using `DOCUMENT_REFERRER` URL substitution as described in [Access URL Variables][7]. The view counting can be done using Pingback endpoint on the server-side. This is very similar to the metering implementation described in [Metering][12].
 
 ## Login Flow
+
 AMP launches a Login Dialog as a 1st party window or a popup or a tab. Whenever possible, AMP Viewers should attempt to launch Login Dialog in the browser context so that it can take advantage of the top-level browser APIs.
 
 The login flow is started by the AMP Runtime when the Reader activates the Login Link and, descriptively, it follows the following steps:
@@ -428,7 +427,7 @@ The login flow is started by the AMP Runtime when the Reader activates the Login
 
 Only steps 2-5 require handling by the Publisher: the Publisher only provides their own Login Page and ensures correct redirect once it completes. There are no special constraints imposed on the login page, other than it should function well as a dialog.
 
-As usual, the Reader ID should be included in the call to Login Page and can be used by the Publisher for identity mapping. As a 1st party window, the Publisher will also receive their cookies and will be able to set them. If it turns out that the Reader is already signed-in on the Publisher's side, it is recommended that the publisher immediately redirect back to the "Return URL" with the `success=true` response.
+As usual, the Reader ID should be included in the call to Login Page and can be used by the Publisher for identity mapping. As a 1st party window, the Publisher will also receive their cookies and will be able to set them. If it turns out that the Reader is already signed-in on the Publisher’s side, it is recommended that the publisher immediately redirect back to the "Return URL" with the `success=true` response.
 
 ## AMP Glossary
  - **AMP Document** - the HTML document that follows AMP format and validated by AMP Validator. AMP Documents are cacheable by Google AMP Cache.
@@ -442,21 +441,21 @@ As usual, the Reader ID should be included in the call to Login Page and can be
  - **AMP Prerendering** - AMP Viewers may take advantage of prerendering, which renders a hidden document before it can be shown. This adds a significant performance boost. But it is important to take into account the fact that the document prerendering does not constitute a view since the Reader may never actually see the document.
 
 ## Revisions
-- Feb 1: "return" query parameter for Login Page can be customized using RETURN_URL URL substitution.
-- Feb 3: Spec for "source origin" security added to the [CORS Origin security][9].
-- Feb 9: [First-click-free][13] and [Metering][12] sections.
-- Feb 11: Nested field references such as `object.field` are now allowed.
-- Feb 11: Authorization request timeout in [Authorization Endpoint][4].
-- Feb 15: [Configuration][8] and [Authorization Endpoint][4] now allow "authorizationFallbackResponse" property that can be used when authorization fails.
-- Feb 19: Corrected samples to remove `{}` from URL var substitutions.
-- Mar 3: Resend pingback after login (v0.5).
-- Sept 2: "noPingback" configuration property and optional pingback.
+- 2016-Sep-02: "noPingback" configuration property and optional pingback.
+- 2016-Mar-03: Resend pingback after login (v0.5).
+- 2016-Feb-19: Corrected samples to remove `{}` from URL var substitutions.
+- 2016-Feb-15: [Configuration][8] and [Authorization Endpoint][4] now allow "authorizationFallbackResponse" property that can be used when authorization fails.
+- 2016-Feb-11: Authorization request timeout in [Authorization Endpoint][4].
+- 2016-Feb-11: Nested field references such as `object.field` are now allowed.
+- 2016-Feb-09: [First-click-free][13] and [Metering][12] sections.
+- 2016-Feb-03: Spec for "source origin" security added to the [CORS Origin security][9].
+- 2016-Feb-01: "return" query parameter for Login Page can be customized using RETURN_URL URL substitution.
 
 ## Appendix A: “amp-access” expression grammar
 
 The most recent BNF grammar is available in [access-expr-impl.jison](./0.1/access-expr-impl.jison) file.
 
-The key excerpt of this grammar is as following:
+The key excerpt of this grammar is below:
 ```javascript
 search_condition:
     search_condition OR search_condition
@@ -485,11 +484,11 @@ field_ref: field_ref '.' field_name | field_name
 literal: STRING | NUMERIC | TRUE | FALSE | NULL
 ```
 
-Notice that `amp-access` expressions are evaluated by the AMP Runtime and Google AMP Cache. This is NOT part of the specification that the Publisher needs to implement. It is here simply for informational properties.
+Notice that `amp-access` expressions are evaluated by the AMP Runtime and Google AMP Cache. This is NOT part of the specification that the Publisher needs to implement. It is here simply for informational purposes.
 
 ## Detailed Discussion
 
-This section will cover a detailed explanation of the design underlying the amp-access spec, and clarify design choices. Coming soon
+This section will cover a detailed explanation of the design underlying the amp-access spec, and clarify design choices. Coming soon.
 
 [1]: #appendix-a-amp-access-expression-grammar
 [2]: #amp-reader-id