[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: pass
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: pass |
Date: |
Mon, 20 Dec 2021 21:02:42 +0100 |
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 66b1d77 pass
66b1d77 is described below
commit 66b1d7711b8a5d104559e3a46f09c730d451defa
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 20 21:02:39 2021 +0100
pass
---
draft-schanzen-gns.xml | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 0b1e901..79092c2 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1012,7 +1012,8 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<section anchor="gnsrecords_box" numbered="true" toc="default">
<name>BOX</name>
<t>
- In GNS, every "." in a name delegates to another zone, and
+ In GNS, with the notable exception of zTLDs, every "." in a name
+ delegates to another zone, and
GNS lookups are expected to return all of the required useful
information in one record set. This is incompatible with the
special labels used by DNS for SRV and TLSA records. Thus, GNS
@@ -1121,9 +1122,9 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<section anchor="publish" numbered="true" toc="default">
<name>Record Storage</name>
<t>
- In general any API which allows storing a value under a key and
retrieving
+ Any API which allows storing a value under a key and retrieving
a value from the key can be used by an implementation for record
storage.
- It is expected that a GNS implementations use distributed or
decentralized
+ It is expected that GNS implementations use distributed or decentralized
storages such as distributed hash tables (DHT) in order to facilitate
availability within a network without the need of servers.
Specification of such a distributed or decentralized storage is out of
@@ -1141,8 +1142,8 @@ value := GET(key)
<t>
In GNS, resource records are grouped by their respective labels,
encrypted and published together in a single resource records block
- (RRBLOCK) in the storage under a key "q": PUT(q, RRBLOCK).
- The key "q" is derived from the Zone Key and the respective
+ (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK).
+ The key q is derived from the zone key and the respective
label of the contained records. The storage key derivation and records
block creation is specified in the following sections.
A client implementation must enable the user the manage zones and use
the
@@ -1151,7 +1152,7 @@ value := GET(key)
<section anchor="blinding" numbered="true" toc="default">
<name>Storage Key</name>
<t>
- Given a label, the storage key "q" is derived as follows:
+ Given a label, the storage key q is derived as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
q := SHA512 (HDKD-Public(zk, label))
@@ -1385,9 +1386,9 @@ q := SHA512 (HDKD-Public(zk, label))
</t>
<t>
GNS clients MUST first try to interpret the top-level domain of
- a GNS name as a zone key representation ("zTLD").
+ a GNS name as a zone key representation (i.e. a zTLD).
If the top-level domain is indicated to be a label representation of
- a public zone key with a well-defined "ztype" value, the root zone of
+ a public zone key with a supported zone type value, the root zone of
the resolution process is implicitly given by the suffix of the name:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1414,7 +1415,7 @@ com = (d2,zk2)
=> Name to resolve from entry zone: www.example
]]></artwork>
<t>
- Finally, additional "suffix to zone" mappings MAY be configured.
+ Finally, additional "suffix-to-zone" mappings MAY be configured.
Suffix to zone key mappings MUST be configurable through a local
configuration file or database by the user or system administrator.
The suffix MAY consist of multiple GNS labels concatenated with a
@@ -1459,7 +1460,7 @@ example.com = zk2
Upon receiving the RRBLOCK from the storage, apart from verifying
the
provided signature, the resolver MUST check that the authoritative
zone key was used to sign the record:
- The derived zone key "h*zk" MUST match the public key provided in
+ The derived zone key zk' MUST match the public key provided in
the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the storage
lookup GET(q) MUST continue.
</t>
@@ -1764,24 +1765,24 @@ NICK: john (Supplemental)
</dd>
<dt>PUBLIC KEY</dt>
<dd>
- is the 256-bit public key "zk" of the zone which is being revoked
and
+ is the 256-bit public key zk of the zone which is being revoked and
the key to be used to verify SIGNATURE. The
wire format of this value is defined in <xref target="RFC8032" />,
Section 5.1.5.
</dd>
</dl>
<t>
- Traditionally, PoW schemes require to find a "POW" such that
+ Traditionally, PoW schemes require to find a POW such that
at least D leading zeroes are found in the hash result.
- D is then referred to as the "difficulty" of the PoW.
+ D is then referred to as the difficulty of the PoW.
In order to reduce the variance in time it takes to calculate the
- PoW, we require that a number "Z" different PoWs must be
- found that on average have "D" leading zeroes.
+ PoW, we require that a number Z different PoWs must be
+ found that on average have D leading zeroes.
</t>
<t>
The resulting proofs may then published and disseminated. The concrete
dissemination and publication methods are out of scope of this
- document. Given an average difficulty of "D", the proofs have an
+ document. Given an average difficulty of D, the proofs have an
expiration time of EPOCH. With each additional bit difficulty, the
lifetime of the proof is prolonged for another EPOCH.
Consequently, by calculating a more difficult PoW, the lifetime of the
@@ -1861,7 +1862,7 @@ NICK: john (Supplemental)
</dd>
<dt>ZONE PUBLIC KEY</dt>
<dd>
- is the public key "zk" of the zone which is being revoked and
+ is the public key zk of the zone which is being revoked and
the key to be used to verify SIGNATURE.
</dd>
<dt>SIGNATURE</dt>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: pass,
gnunet <=