lsd0001

commit f8eac4df748686f94a1795ba52ca914e01565aba
parent 505d0083092d12265f6644d51ff697391b7d3b70
Author: Christian Grothoff <christian@grothoff.org>
Date:   Fri, 30 Jun 2023 18:25:46 +0200

be consistent in referencing sections

Diffstat:
M
draft-schanzen-gns.xml
 | 
6
+++---

1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -375,11 +375,11 @@ example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
          builds on ideas from the Simple Distributed Security Infrastructure
          <xref target="SDSI" />.
          In GNS, any user can create and manage any number of zones
-         (<xref target="zones"/>) if their system provides a zone master implementation.
+         (see <xref target="zones"/>) if their system provides a zone master implementation.
          For each zone, the zone type determines the respective set of cryptographic operations
          and the wire formats for encrypted data, public keys and signatures.
          A zone can be populated with mappings from labels to resource records
-         (<xref target="rrecords"/>) by its owner.
+         (see <xref target="rrecords"/>) by its owner.
          A label can be mapped to a delegation record which results in the
          corresponding subdomain being delegated to another zone. Circular
          delegations are explicitly allowed, including delegating a subdomain
@@ -390,7 +390,7 @@ example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
        </t>
        <t>
          Zone contents are encrypted and signed
-         before being published in a key-value storage (<xref target="publish"/>)
+         before being published in a key-value storage (see <xref target="publish"/>)
          as illustrated in <xref target="figure_arch_publish"/>.
          In this process, unique zone identification is hidden from the network
          through the use of key blinding.