diff --git a/README.md b/README.md
index e5b42bf..da880ba 100644
--- a/README.md
+++ b/README.md
@@ -27,21 +27,21 @@ specification to describe this ability as well, and move the document to the sta
   Here are two main types of updates that are beneficial if done opportunistically:
   1. Updating state:
      This is the data required for the correct functioning of the app. Examples:
-     a. Updated search index for a search app.
-     b. Synchronized game scores for the user and their friends for a gaming app.
-     c. Updated icons after a UI overhaul of a web app.
+     * Updated search index for a search app.
+     * Pushing a critical application update.
+     * Updated icons after a UI overhaul of a web app.
 
   2. Updating content:
      Periodic content producers can push content to user devices, to be consumed at a later, more
      convenient time. Examples:
-     a. Fresh articles from news sites.
-     b. List of badges the user has earned, in a fitness app.
-     c. List of new songs from their favorited artists, in a songs app, to be downloaded using
+     * Fresh articles from news sites.
+     * List of badges the user has earned, in a fitness app.
+     * List of new songs from their favorited artists, in a songs app, to be downloaded using
         Background Fetch if the user clicks on "Download".
 
   Currently, the Push API enables this, but it requires setting up a server that speaks the Web
-  Push protocol, and is GDPR compliant. Additional tasks like resource management add complexity to
-  this approach. Periodic Background Sync offers a simpler, more accessible solution.
+  Push protocol. Additional tasks like resource management add complexity to this approach. Periodic
+  Background Sync offers a simpler, more accessible solution.
 
 ## Why do we care?
   * Native apps currently have the ability to offer fresh content to users, even when they're 
@@ -60,9 +60,12 @@ specification to describe this ability as well, and move the document to the sta
 ## Non-goals
 * Triggering events at a specific time is an explicit non-goal. A more generalized alarms API can
 enable that.
-* Multiple periodic tasks per origin, with varying frequency. The browser decides the cadence of
-  periodic sync tasks for each origin. An origin can thus register multiple periodic tasks, but the
-  frequency decided by the browser for the tasks can be the same.
+* Guaranteed cadence of the periodic sync tasks. The browser decides this cadence for each origin.
+An origin can thus register multiple periodic tasks, but the frequency decided by the browser for
+the tasks might be the same.
+* Shared namespace for one-shot and periodic sync tasks is not a goal. The same tag can thus be used
+for a one-shot and a periodic sync task. However, two one-shot Background Sync tasks or two periodic
+Background Sync tasks can't share a tag.
 
 # Example code
 
@@ -116,8 +119,7 @@ navigator.serviceWorker.ready.then(registration => {
 
 One-shot Background Sync allows the web page’s logic to live a little longer (service worker
 execution time) after the page has been closed by the user. Periodic Background Sync extends it to
-potentially run forever, at regular periods, for a few minutes at a time. Here are some privacy
-concerns:
+potentially run at regular periods, for a few minutes at a time. Here are some privacy concerns:
 
 * There might be no notification to the user, depending on the implementation.
 * A periodic sync can be enabled while the user is connected to one network, and the sync event
@@ -148,6 +150,19 @@ honors the requested `minInterval` between two consecutive events.
 The interfaces mimic regular Background Sync, but substitute `navigator.sync` with
 `navigator.periodicSync` for symmetry with the event that will be fired in the service worker.
 
+## Power and Network conditions
+The original explainer allowed the website to specify power and network conditions under which the
+periodic task should be run. This proposal leaves those decisions to the browser implementation,
+because we believe the browser is better positioned to make those choices for the user. This also
+makes for a simpler interface for developers.
+
+## Timing of periodic sync tasks
+The API allows the developer to specify a `minInterval` for each periodic sync task. The browser is
+expected to guarantee a minimum of this time interval between two periodic sync events. However, the
+interval between any two periodic sync events can be greater than the requested `minInterval`, and
+is up to the browser implemetation. Also, the interval between any two periodic sync events for a
+registration doesn't have to be the same.
+
 # References and acknowledgements
 
   * [Background Sync](https://wicg.github.io/BackgroundSync/spec/)