diff --git a/Use-Cases.md b/Use-Cases.md
index 2ce3238..11c0c7c 100644
--- a/Use-Cases.md
+++ b/Use-Cases.md
@@ -88,7 +88,7 @@ In this alternative, the vector layer has no source set - meaning the user will
 
 _Questions/comments from Eric:_
 
-In my alternative, and based on my comments for the previous use-case, the app would add features to the store.
+In my alternative, and based on my comments for the previous use-case, the app would add features to the source.
 
 **Alternative 2**
 
@@ -127,6 +127,8 @@ vector.getSource().addFeatures(parser, {
 });
 ```
 
+`addFeatures` would add the data to the source, but wouldn't transform the data (the source doesn't know about the view projection). Again, the data would be transformed on the next `render` pass.
+
 ### Load data based on map extent
 
 User has a service that provides vector features for requests with an arbitrary BBOX (e.g. a WFS).  Data source contains hundreds of millions of features with worldwide coverage (e.g. OSM) and the user only wants to display a small subset, updating rendered features as the user navigates around the map.
@@ -153,6 +155,12 @@ var map = new ol.Map({
 
 This alternative can be implemented if the layer knows about the map.  The WFS layer creates a WFS protocol, a GML parser, a BBOX strategy by default.  The layer creates a vector source with the protocol and the parser (these are the two things associated with the data source).  The bbox strategy listens for changes in map extent.  When the previous data bounds become invalid, the bbox strategy notifies the layer that new data is needed, and the layer calls `source.protocol.read({success: callback})`.  The provided callback would call `source.parser.readFeatures(data, {projection: projection})` with the provided data and the map view's projection.  The resulting features would replace the existing features (or new ones would be added and features outside the data bounds would be removed).
 
+_Questions/comments from Eric:_
+
+The API looks good to me, although, again, I think a projection should be specified in the source options if the projection of the data received from the server isn't the same as the view projection.
+
+Why does the strategy need to listen for view changes? As the map moves, the layer renderer requests more data from the source. The source can then request data from the server, using a strategy that depends on the strategy configured in the source. For example, if the strategy is a bbox strategy the first tile request from the Canvas renderer will trigger a server request for the entire view extent (a sort of meta-tile). Bottom line is I think it would be good not to have multiple paths of communication between map/renderer and layer/source, `renderFrame` is the communication path.
+
 ### Edit existing features and synchronize them with a server
 
 The user loads a vector layer with a very large number of features.  He then modifies a few of them, and saves the modified features back to the server.  The feature currently being edited should be on top, and the system should maintain good performance even if the underlying layer contains a very large number of features.  Only the modified features should be sent back to the server.  Example case: editing OSM building outlines.