commit 118c58412c3c34832eb304618c922ade8241b090
parent d7fe59a9f4f8253e42ecf785cdf176455d54461d
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 21 Feb 2022 13:13:23 +0100
fixes
Diffstat:
1 file changed, 32 insertions(+), 34 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -227,9 +227,7 @@
</dd>
<dt>Extension Label</dt>
<dd>
- If a name ends with the extension label the rest of the name
- <bcp14>MUST</bcp14> be interpreted relative to the current zone in the resolution process.
- The primary use for this is in redirections where the redirection
+ The primary use for the extension label is in redirections where the redirection
target is defined relative to the authoritative zone of the redirection
record (<xref target="gnsrecords_redirect"/>).
The extension label is represented using the character U+002B ("+"
@@ -373,17 +371,15 @@
<section anchor="zones" numbered="true" toc="default">
<name>Zones</name>
<t>
- A zone in GNS is uniquely identified by its zone type and zone key.
- Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
- </t>
- <t>
An implementation <bcp14>SHOULD</bcp14> enable the user to create and manage zones.
If this functionality is not implemented, names can still be resolved
if zone keys for the initial step in the name resolution are available
(see <xref target="resolution"/>).
</t>
<t>
- Each zone type (ztype) is a unique 32-bit number.
+ A zone in GNS is uniquely identified by its zone type and zone key.
+ Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
+ A zone type (ztype) is a unique 32-bit number.
This number corresponds to a resource record type number
identifying a delegation record type
in the GNUnet Assigned Numbers Authority <xref target="GANA" />.
@@ -676,9 +672,8 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
denotes the relative 64-bit time to live of the record in
microseconds also in network byte order.
The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1.
- If the average number of leading zeros D' is larger than
- D, then the field value <bcp14>MAY</bcp14> be increased up to
- (D'-D) * EPOCH * 1.1.
+ Given an average number of leading zeros D', then the field value
+ <bcp14>MAY</bcp14> be increased up to (D'-D) * EPOCH * 1.1.
The EPOCH is extended by
10% in order to deal with unsynchronized clocks.
This field is informational for a verifier.
@@ -774,7 +769,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<li>The set of POW values <bcp14>MUST</bcp14> NOT contain duplicates which <bcp14>MUST</bcp14> be checked by verifying that the values are strictly monotonically increasing.</li>
<li>The average number of leading zeroes D' resulting from the provided
POW values <bcp14>MUST</bcp14> be greater than and not equal to D. Implementers
- <bcp14>MUST</bcp14> NOT use an integer data type to calculate or represent D'.</li>
+ <bcp14>MUST NOT</bcp14> use an integer data type to calculate or represent D'.</li>
<li>
The validity period of the revocation is calculated as
(D'-D) * EPOCH * 1.1. The EPOCH is extended by
@@ -785,8 +780,11 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
the TTL field value, the verifier <bcp14>MUST</bcp14> continue and
use the calculated value when forwarding the revocation.
</li>
- <li>The current time <bcp14>SHOULD</bcp14> be between TIMESTAMP and
- TIMESTAMP + validity period. Implementations <bcp14>MAY</bcp14> process the revocation without validating this.</li>
+ <li>
+ The current time <bcp14>SHOULD</bcp14> be between TIMESTAMP and
+ TIMESTAMP + validity period.
+ Implementations <bcp14>MAY</bcp14> process the revocation without validating this.
+ </li>
</ol>
</section>
@@ -859,9 +857,9 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
</dl>
<t>
Flags indicate metadata surrounding the resource record.
- Applications creating resource records <bcp14>MUST</bcp14> set all bits which are
- not defined as a flag to 0. Additional flags may be defined in
- future protocol versions.
+ An application creating resource records <bcp14>MUST</bcp14> set all bits
+ to 0 unless it wants to set the respective flag.
+ Additional flags may be defined in future protocol versions,
If an application or implementation encounters a flag which it does not
recognize, it <bcp14>MUST</bcp14> be ignored.
Any combination of the flags specified below are valid.
@@ -913,7 +911,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
the respective zone type is encountered.
This may be a valid choice if some zone delegation record types have been
determined to be cryptographically insecure.
- Zone delegation records <bcp14>MUST</bcp14> NOT be stored and published
+ Zone delegation records <bcp14>MUST NOT</bcp14> be stored and published
under the apex label.
A zone delegation record type value is the same as the respective ztype
value.
@@ -921,8 +919,8 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
being delegated to.
A zone delegation record payload contains the public key of
the zone to delegate to.
- A zone delegation record <bcp14>MUST</bcp14> have the CRTITICAL flag set.
- A zone delegation record <bcp14>MUST</bcp14> be the only record under a label.
+ A zone delegation record <bcp14>MUST</bcp14> have the CRTITICAL flag set
+ and <bcp14>MUST</bcp14> be the only record under a label.
No other records are allowed.
</t>
<section anchor="gnsrecords_pkey" numbered="true" toc="default">
@@ -1378,11 +1376,11 @@ S-Decrypt(zk,label,expiration,ciphertext):
and <bcp14>MAY</bcp14> support any number of additional redirection records defined in
the GNU Name System Record Types registry (see Section <xref target="gana"/>).
Redirection records <bcp14>MUST</bcp14> have the CRTITICAL flag set.
- Not supporting some record types <bcp14>MAY</bcp14> result in resolution failures.
- This <bcp14>MAY</bcp14> BE a valid choice if some redirection record types have been
+ Not supporting some record types may consequently result in resolution failures.
+ This may be a valid choice if some redirection record types have been
determined to be insecure, or if an application has reasons to not
support redirection to DNS for reasons such as complexity or security.
- Redirection records <bcp14>MUST</bcp14> NOT be stored and published under the apex label.
+ Redirection records <bcp14>MUST NOT</bcp14> be stored and published under the apex label.
</t>
<section anchor="gnsrecords_rdr" numbered="true" toc="default">
<name>REDIRECT</name>
@@ -1639,7 +1637,7 @@ GET(key) -> value
record would require a revocation of the record.
In GNS, zones can only be revoked as a whole. Records automatically
expire and it is under the discretion of the storage as to when to delete
- the record. The GNS implementation <bcp14>MUST</bcp14> NOT publish expired resource
+ the record. The GNS implementation <bcp14>MUST NOT</bcp14> publish expired resource
records. Any GNS resolver <bcp14>MUST</bcp14> discard expired records returned from
the storage.
</t>
@@ -1856,7 +1854,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
ignored on receipt.
As a special exception, record sets with (only) a zone delegation
record type are never padded.
- Note that a record set with a delegation record <bcp14>MUST</bcp14> NOT
+ Note that a record set with a delegation record <bcp14>MUST NOT</bcp14>
contain other records. If other records are encountered, the whole
record block <bcp14>MUST</bcp14> be discarded.
</dd>
@@ -1881,7 +1879,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
For example, if a zone delegation record type is requested, the
resolution of the apex label in that zone must be skipped, as
the desired record is already found.
- The resolver implementation <bcp14>MUST</bcp14> NOT filter results according to the desired
+ The resolver implementation <bcp14>MUST NOT</bcp14> filter results according to the desired
record type.
Filtering of record sets is typically done by the application.
</t>
@@ -1931,7 +1929,7 @@ Example name: www.example.<zTLD>
label separator.
If multiple suffixes match the name to resolve, the longest
matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two results
- <bcp14>MUST</bcp14> NOT be equal. This indicates a misconfiguration and the
+ <bcp14>MUST NOT</bcp14> be equal. This indicates a misconfiguration and the
implementation <bcp14>MUST</bcp14> return an error.
The following is a non-normative example mapping of start zones:
</t>
@@ -2118,7 +2116,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
<t>
As the DNS servers
specified are possibly authoritative DNS servers, the GNS resolver <bcp14>MUST</bcp14>
- support recursive DNS resolution and <bcp14>MUST</bcp14> NOT delegate this to the
+ support recursive DNS resolution and <bcp14>MUST NOT</bcp14> delegate this to the
authoritative DNS servers.
The first successful recursive name resolution result
is returned to the application.
@@ -2129,9 +2127,9 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
<t>
Once the transition from GNS into DNS is made through a
GNS2DNS record, there is no "going back".
- The (possibly recursive) resolution of the DNS name <bcp14>MUST</bcp14> NOT
+ The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT</bcp14>
delegate back into GNS and should only follow the DNS specifications.
- For example, names contained in DNS CNAME records <bcp14>MUST</bcp14> NOT be
+ For example, names contained in DNS CNAME records <bcp14>MUST NOT</bcp14> be
interpreted as GNS names.
</t>
<t>
@@ -2174,11 +2172,11 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
resolution <bcp14>MUST</bcp14> fail with an empty result set.
</t>
<t>
- Implementations <bcp14>MUST</bcp14> NOT allow multiple different zone
+ Implementations <bcp14>MUST NOT</bcp14> allow multiple different zone
delegations under a single label.
Implementations <bcp14>MAY</bcp14> support any subset of ztypes.
Handling of
- Implementations <bcp14>MUST</bcp14> NOT process zone delegation for the apex
+ Implementations <bcp14>MUST NOT</bcp14> process zone delegation for the apex
label "@". Upon encountering a zone delegation record under
this label, resolution fails and an error <bcp14>MUST</bcp14> be returned. The
implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
@@ -2288,7 +2286,7 @@ NICK: john (Supplemental)
select a default ztype considered secure at the time of
releasing the software.
For applications targeting end users that are not expected to
- understand cryptography, the application developer <bcp14>MUST</bcp14> NOT leave
+ understand cryptography, the application developer <bcp14>MUST NOT</bcp14> leave
the ztype selection of new zones to end users.
</t>
<t>
@@ -2460,7 +2458,7 @@ NICK: john (Supplemental)
to manage revocations accordingly.
</t>
<t>
- Revocation payloads do NOT include a 'new' key for key replacement.
+ Revocation payloads do not include a 'new' key for key replacement.
Inclusion of such a key would have two major disadvantages:
</t>
<ol>
