be consistent in referencing sections

1 files changed, 3 insertions, 3 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index b09902f..19a8a12 100644
--- 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.