--- a/network-api/Overview.html	Fri Nov 23 14:24:17 2012 +0200
+++ b/network-api/Overview.html	Fri Nov 23 15:14:23 2012 +0000
@@ -59,12 +59,11 @@
       <section>
         <h2>Use Cases</h2>
         <p>
-          The main use cases trying to be solved by the Network Information API
-          are use cases of applications trying to be gentle with the user's
-          bandwidth when they know it is rare or expensive.<br>
-          Even if they are not much applications trying to behave like that
-          currently, this specification tries to build the required tools to
-          allow this and hopefully making it more common.
+          The main use case of the Network Information API is to allow
+          applications to be gentle with the user's bandwidth when they know it
+          is rare or expensive. Even if there are not many applications that do
+          this currently, this specification offers the the tools needed to
+          enable this, allowing it to become more common.
         </p>
         <p>
           A few hypothetical examples would be:
@@ -85,28 +84,28 @@
       <section>
         <h2>Outstanding issues</h2>
         <p>
-          The specification currently request the <dfn>user agent</dfn> to show
-          two properties: <code>bandwidth</code> and <code>metered</code>. Both
-          are currently facing some disagreements.
+          The specification currently requests the <dfn>user agent</dfn> to
+          expose two properties: <code>bandwidth</code> and
+          <code>metered</code>. The working group currently does not have
+          consensus on these.
         </p>
         <p>
-          <code>bandwidth</code> is told to be hard to implement, can be quite
-          power-consuming to keep it up-to-date and its value might be unrelated
-          to the actual connection quality but could be affected by the server.
-          <br>
+          One concern is that <code>bandwidth</code> may be hard to implement,
+          can be quite power-consuming to keep up-to-date and its value might be
+          unrelated to the actual connection quality that could be affected by
+          the server.<br>
           A solution to fix this would be to return non absolute values that
           couldn't be easily abused and would be more simple to produce for the
           <dfn>user agent</dfn>. For example, having a set of values like
           <code>very-slow</code>, <code>slow</code>, <code>fast</code> and
-          <code>very-fast</code>.<br>
-          Another solution would be to have only values like
-          <code>very-slow</code>, <code>slow</code> and the empty string.
+          <code>very-fast</code>. Another solution would be to have only values
+          like <code>very-slow</code>, <code>slow</code> and the empty string."
         </p>
         <p>
-          <code>metered</code> is also told to be hard to implement because
-          there is currently no standard way for the OS to know if the current
-          connection is metered but the idea of the specification is to leave
-          the implementation details to the <dfn>user agent</dfn>. That way, the
+          <code>metered</code> may also be hard to implement as there is
+          currently no standard way for the OS to know if the current connection
+          is metered.  The approach of the specification is to leave the
+          implementation details to the <dfn>user agent</dfn>. That way, the
           attribute could return a value based on a heuristic, on knowledge of
           the current connection status or even by directly asking the user for
           the information.<br>
@@ -338,7 +337,7 @@
                 }
 
                 gPreviousMetered = navigator.connection.metered;
-                if (navigator.connection.metered) {
+                if (!navigator.connection.metered) {
                   gIntervalId = setInterval(poll, 1000);
                 } else {
                   clearInterval(gIntervalId);
@@ -361,7 +360,7 @@
     <section class='appendix'>
       <h2>Acknowledgments</h2>
       <p>
-        Special thanks to Robin Berjon for his help.
+        Thanks to Robin Berjon, Frederick Hirsch and Jonas Sicking for their help.
       </p>
     </section>
   </body>