diff --git a/libraries/entities/src/todo.txt b/libraries/entities/src/todo.txt
index 240eb15297..05a9d1add4 100644
--- a/libraries/entities/src/todo.txt
+++ b/libraries/entities/src/todo.txt
@@ -35,16 +35,24 @@ Model properties:
 
     1) verify lots of models in single element works
         -- repro case - run editModelsExample.js -- create 10 models in the same octree element
-         -- problem 1:
-                it appears as if on a second pass on the element a DONT_FIT case occurs and this confuses things...
 
 
-         -- problem 2:
-                sometimes it appears as if the element entities mostly fit, but then the extra data (bit masks) fails
-                to fit and in this case the "extra data" gets confused...
-                    maybe remember the extra state before removing it and if it fails, always re-add it
-                    maybe add support for "reserving" bytes in the packet
-
+**************************
+    2) ROOT ELEMENT and/or partial element data...
+       BREAKS File persistence...
+            * problem is that in reading back the file, we don't know the END of the PACKET...
+              the old code could read along and just know that the elements would always end on 
+              another element boundary
+              
+              this doesn't work with the current code because ?????
+              
+                is it the root element logic?? or something else?
+                
+                try disabling root element persistance and see if the files read.
+                
+                or consider storing buffer sizes in the persisted file format
+                   this would allow for us to do partial reads of the persited file which would be a nice bonus
+**************************
                 
    
 
@@ -240,3 +248,10 @@ Model properties:
 // SOLVED - 12) change delete to use delete messages instead of shouldBeDeleted property
 // SOLVED - 12a) make sure server is deleting items??
 // SOLVED - 12b) Use the delete message instead of shouldDelete property
+// SOLVED -- problem 1:
+//                 it appears as if on a second pass on the element a DONT_FIT case occurs and this confuses things...
+// SOLVED -- problem 2:
+//                 sometimes it appears as if the element entities mostly fit, but then the extra data (bit masks) fails
+//                 to fit and in this case the "extra data" gets confused...
+//                     maybe remember the extra state before removing it and if it fails, always re-add it
+//                     maybe add support for "reserving" bytes in the packet