finish first pass

2 files changed, 13 insertions, 13 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 50f71cd..1f0ef16 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -2534,7 +2534,9 @@ NICK: john (Supplemental)
            by having the respective domains seized by authorities.
            However, the same mechanisms can also be abused in order to impose
            state censorship, which is one of the motivations behind GNS.
-           Hence, such a seizure is, by design, difficult to impossible in GNS.
+           In GNS, TLDs are not enumerable. By design, the start zone of
+           the resolver is defined locally and hence such a seizure is
+           difficult and ineffective in GNS.
            <!--In particular, GNS does not support WHOIS (<xref target="RFC3912" />).-->
          </t>
        </section>
@@ -2548,7 +2550,8 @@ NICK: john (Supplemental)
            Zone administrators, and for GNS this includes end-users, are
            required to responsibly and diligently protect their cryptographic
            keys.
-           GNS supports offline signing of records.
+           GNS supports signing records in advance ("offline") in order to
+           support processes which aim to protect private keys such as air gaps.
            <!-- It does not support separate zone signing and key-signing keys
            (as in <xref target="RFC6781" />) in order to provide usable security. This is not useful for any implementer -->
          </t>
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.