1 files changed, 8 insertions, 11 deletions

diff --git a/rs_review_202204.txt b/rs_review_202204.txt
index 3b28856..e6e8e34 100644
--- a/rs_review_202204.txt
+++ b/rs_review_202204.txt
@@ -14,7 +14,7 @@ Some people might be offended by "limiting" IANA registrations (e.g., Sec 5.3.3'
 
 This seems incomplete, since an implementation needs to be able to talk to remote storage (i.e., the GET in sec 7ff), and that is not defined. Does the storage need to be globally consistent? What if two views diverge?  Suggest you discuss that. Somewhat addressed in section 9.5, should be joined with the other global storage sections in my view.  Okay if you disagree.
 
-======= TODO address this somehow?
+======= We think 9.5 is good enough
 
 Some minor items, or nits, follow. None of them, in my view, are intended to block publication.
 
@@ -37,7 +37,7 @@ In the "Name" definition, do you mean "applications MAY *require* that ... "?
 
 Using "Zone type" as the term for cipher and encoding seemed strange to me, why not "Zone Representation" or something shorter?  One or two examples before the terms, with text identifying the parts in the definition, would be helpful.
 
-===== Unclear.
+===== Unclear, should the terminology be moved?
 
 Sec 3, "cryptographically secured zones" is redundant, aren't all zones cryptographically secured?
 
@@ -111,22 +111,19 @@ Sec 9.3 seems very important.  Somewhere up near the front you should forward-li
 
 Sec 9.4, it's difficult because it requires law enforcement, etc., to get the private key?  Is that really so hard? https://xkcd.com/538/
 
-==== No, because of the user-centric design for delegations. TODO: Clarify again in text?
-Because in GNS a zone does not necessarily have a single/unique parent zone.
-The top-level domains are not enumerable.
-The as the root zone is defined locally it is not enumerable.
+===== A misunderstanding that this is related to the private keys. Added a reasoning.
 
 Sec 9.5, "offline signing of records"  not quite sure, maybe a better word, but I cannot think of one.
 
+==== Signing of records in advance ("offline")
+
 Sec 9.6, this belongs with Sec 6 I think.  Should the DHT be part of the zone type?
 
-==== That is an interesting question!
-==== Introduce STORAGE record which defined the storage type. "Default": GNUnet.
-==== Storage: Typenum (GANA) + Metadata e.g. 3294 (REST) + "https://example.com". OR 0 => R5N/GNUnet w/o metadata
-==== Or rather not?
+==== That is an interesting question! We could introduce STORAGE record which defined the storage type. Example: Storage: Typenum (GANA) + Metadata e.g. 3294 (REST) + "https://example.com". OR 0 => R5N/GNUnet w/o metadata
+==== But, this would require a "glue" from the delegating zone: The zone owner must know the storages where the delegated zone exists. Any changes will have delays/inconsistencies. We decided to document this for a possible update of the protocol if the need arises. For now, it would be too complex and there is no real use case for this.
 
 Sec 9.7 is good.
 
 Sec 12, last sentence of paragraph 1. "given that they are built on top of the same underlying DHT storage." Does that mean *any* implementation should interoperate? Does an implementation *have to use* the DHT storage?
 
-===== Fixed. Only If.
+===== Fixed: Only If.