[lsd0001] branch master updated: typos

[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 7368380  typos
7368380 is described below

commit 73683803c0040e354dbce107d091539524e3bb38
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Jan 16 18:38:09 2022 +0100

    typos
---
 draft-schanzen-gns.xml | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 518cd03..8434063 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -245,7 +245,7 @@
        <t>
          For any zone, d is the private zone key. zk is the public zone key.
          The specific formats depends on the zone type.
-         The creation of zone keys for the default zone types are specificed in
+         The creation of zone keys for the default zone types are specified in
          <xref target="gnsrecords_delegation"/>.
          New zone types may be specified in the future, for example if the
          cryptographic mechanisms used in this document are broken.
@@ -430,7 +430,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          ahead of time to support timely revocation.
        </t>
        <t>
-         For all occurences below, "Argon2id" is the Password-based Key
+         For all occurrences below, "Argon2id" is the Password-based Key
          Derivation Function as defined in <xref target="RFC9106" />. For the
          PoW calculations the algorithm is instantiated with the
          following parameters:
@@ -664,7 +664,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
        A GNS implementer MUST provide a mechanism to create and manage resource
        records for local zones. A local zone is established by selecting a
        zone type and creating a zone key pair.
-       As records may be added to each created zone, a (local) persistency
+       As records may be added to each created zone, a (local) persistence
        mechanism such as a database for resource records and zones must be 
provided.
        This local zone database is used by the name resolution logic and serves
        as a basis for publishing zones into the GNS storage (see <xref 
target="publish"/>).
@@ -1082,7 +1082,7 @@ zk' := h * zk
            published.
            The multiplication of zk with h is a point multiplication,
            while the division and multiplication of a and a1 with the
-           cofactor are integer operations.
+           co-factor are integer operations.
          </t>
          <t>
            Signatures for EDKEY zones using the derived private key a'
@@ -1229,7 +1229,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          However, sometimes connecting to such services does not only require
          the knowledge of an address and port, but also requires the canonical
          DNS name of the service to be transmitted over the transport protocol.
-         In GNS, legacy hostname records provide applications the DNS name that
+         In GNS, legacy host name records provide applications the DNS name 
that
          is required to establish a connection to such a service.
          The most common use case is HTTP virtual hosting, where a DNS name 
must
          be supplied in the HTTP "Host"-header.
@@ -1396,7 +1396,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          <dt>SERVICE NAME</dt>
          <dd>
            a shared secret used to identify the service at the hosting peer,
-           used to derive the port number requird to connect to the service.
+           used to derive the port number required to connect to the service.
            The service name MUST be a 0-terminated UTF-8 string.
          </dd>
        </dl>
@@ -1768,7 +1768,7 @@ example.com = zk2
      Case 2:
      If the name to be resolved is of the format
      "_SERVICE._PROTO" and the record set contains one or more matching BOX
-     records, the records in the BOX records are the result and the recusion
+     records, the records in the BOX records are the result and the recursion
      is concluded (<xref target="box_processing" />).
    </li>
          <li>
@@ -1846,7 +1846,7 @@ example.com = zk2
              The resolver MAY try them in any order or even in parallel.
              If multiple GNS2DNS records are present, the DNS name MUST be
              identical for all of them, if not the resolution fails and an
-             emtpy record set is returned as the record set is invalid.
+             empty record set is returned as the record set is invalid.
            </t>
            <t>
              Once the IP addresses of the DNS servers have been determined,
@@ -1869,7 +1869,7 @@ example.com = zk2
        Such resolvers would return an empty record set upon encountering
        a GNS2DNS record during the recursion. However, if GNS2DNS records
        are encountered in the record set for the apex and a GNS2DNS record
-       is expicitly requested by the application, such records MUST
+       is explicitly requested by the application, such records MUST
        still be returned, even if DNS support is disabled by the
        GNS resolver configuration.
      </t>
@@ -1999,7 +1999,7 @@ NICK: john (Supplemental)
            This is why developers of applications managing GNS zones SHOULD
            select a default zone type considered secure at the time of
            releasing the software.
-           For applications targetting end users that are not expected to
+           For applications targeting end users that are not expected to
            understand cryptography, the application developer MUST NOT leave
            the zone type selection of new zones to end users.
          </t>
@@ -2066,7 +2066,7 @@ NICK: john (Supplemental)
            Further, DNS can be used to combat illegal content on the internet
            by having the respective domains seized by authorities.
            However, the same mechanisms can also be abused in order to impose
-           state censorship, which ist one of the motivations behind GNS.
+           state censorship, which is one of the motivations behind GNS.
            Hence, such a seizure is, by design, difficult to impossible in GNS.
            In particular, GNS does not support WHOIS (<xref target="RFC3912" 
/>).
          </t>
@@ -2079,7 +2079,7 @@ NICK: john (Supplemental)
            compromised it cannot be revoked (unless a revocation message was
            pre-calculated and is still available).
            Zone administrators, and for GNS this includes end-users, are
-           required to responsibly and dilligently protect their cryptographic
+           required to responsibly and diligently protect their cryptographic
            keys.  Offline signing is in principle possible, but GNS does not
            support separate zone signing and key-signing keys
            (as in <xref target="RFC6781" />) in order to provide usable 
security.
@@ -2099,7 +2099,7 @@ NICK: john (Supplemental)
        <section anchor="security_dht" numbered="true" toc="default">
          <name>Impact of DHTs as Underlying Storage</name>
          <t>
-           This document does not specifiy the properties of the underlying
+           This document does not specify the properties of the underlying
            storage which is required by any GNS implementation.
            For implementers using a DHT as underlying storage, it is important
            to note that the properties of the DHT are directly inherited by the
@@ -2119,7 +2119,7 @@ NICK: john (Supplemental)
          <t>
            Zone administrators are advised to pre-generate zone revocations
            and securely store the revocation information in case the zone
-           key is lost, compromised or replaced in the furture.
+           key is lost, compromised or replaced in the future.
            Pre-calculated revocations may become invalid due to expirations
            or protocol changes such as epoch adjustments.
            Consequently, implementers and users must make precautions in order
@@ -2213,7 +2213,7 @@ NICK: john (Supplemental)
        <t>
          Any request MUST contain a unique name and a point of contact.
          The contact information MAY be added to the registry given the consent
-         of the requestor.
+         of the requester.
          The request MAY optionally also contain relevant references as well
          as a descriptive comment as defined above.
        </t>
@@ -2251,7 +2251,7 @@ Purpose | Name            | References | Comment
      </section>
      <!-- gana -->
      <section>
-       <name>IANA Considertations</name>
+       <name>IANA Considerations</name>
        <t>
          This document makes no requests for IANA action.
          This section may be removed on publication as an RFC.

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