[lsd0001] branch master updated: finish first pass

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 04ac3a5  finish first pass
04ac3a5 is described below

commit 04ac3a5a25f422027201de9c1f35d7e56d9ca05b
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Thu May 5 16:34:52 2022 +0200

    finish first pass
---
 draft-schanzen-gns.xml |  7 +++++--
 rs_review_202204.txt   | 19 ++++++++-----------
 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.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.