lsd0001

commit 44c94a1b79c87ae3293790e3bbe6fa99b0cc3057
parent d8ffbc0e1e80d6a826cd36283ee0cd76f88d4c51
Author: Christian Grothoff <christian@grothoff.org>
Date:   Fri, 30 Jun 2023 23:47:32 +0200

be consistent in referencing sections

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

1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -2128,7 +2128,7 @@ q := SHA-512 (ZKDF(zk, label))
        <t>
          The resolution of a GNS name starts by identifying the start zone
          suffix. Once the start zone suffix is identified, recursive resolution
-         of the remainder of the name is initiated (<xref target="recursion"/>).
+         of the remainder of the name is initiated (see <xref target="recursion"/>).
          There are two types of start zone suffixes: zTLDs and local
          suffix-to-zone mappings.
          The choice of available suffix-to-zone mappings is at the sole
@@ -2143,7 +2143,7 @@ q := SHA-512 (ZKDF(zk, label))
          In order to ensure uniqueness of names with zTLDs any
          implementation <bcp14>MUST</bcp14> use the given zone as start zone.
          An implementation <bcp14>MUST</bcp14> first try to interpret the rightmost label of
-         the given name as the beginning of a zTLD (<xref target="zTLD"/>).
+         the given name as the beginning of a zTLD (see <xref target="zTLD"/>).
          If the rightmost label cannot be (partially) decoded or if it does not
          indicate a supported ztype, the name is treated as a normal name and
          start zone discovery <bcp14>MUST</bcp14> continue with finding a local suffix-to-zone