1 files changed, 143 insertions, 143 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index e5644bc..2a672c6 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -198,9 +198,9 @@
          list of labels concatenated with a label separator.
          Names are resolved starting from the rightmost label.
          GNS does not impose length restrictions on names or labels.
-         However, applications MAY ensure that name and label lengths are
+         However, applications <bcp14>MAY</bcp14> ensure that name and label lengths are
          compatible with DNS and in particular IDNA <xref target="RFC5890"/>.
-         In the spirit of <xref target="RFC5895"/>, applications MAY preprocess
+         In the spirit of <xref target="RFC5895"/>, applications <bcp14>MAY</bcp14> preprocess
          names and labels to ensure compatibility with DNS or support
          specific user expectations, for example according to
          <xref target="Unicode-UTS46"/>.
@@ -213,7 +213,7 @@
          The apex label, label separator and the extension label have
          special purposes in the resolution protocol which are defined
          in the rest of the document.
-         Zone administrators MAY disallow certain labels that may be easily
+         Zone administrators <bcp14>MAY</bcp14> disallow certain labels that may be easily
          confused with other labels through registration policies.
        </dd>
        <dt>Apex Label</dt>
@@ -228,7 +228,7 @@
        <dt>Extension Label</dt>
        <dd>
          If a name ends with the extension label the rest of the name
-         MUST be interpreted relative to the current zone in the resolution process.
+         <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
          target is defined relative to the authoritative zone of the redirection
          record (<xref target="gnsrecords_redirect"/>).
@@ -377,7 +377,7 @@
        Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
      </t>
      <t>
-       A implementation SHOULD enable the user to create and manage zones.
+       A 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"/>).
@@ -390,7 +390,7 @@
        The ztype determines which cryptosystem is used for the
        asymmetric and symmetric key operations of the zone and the format of
        the delegation record type.
-       Any ztype MUST define the following set of cryptographic functions:
+       Any ztype <bcp14>MUST</bcp14> define the following set of cryptographic functions:
      </t>
      <dl>
        <dt>KeyGen() -> d, zk</dt>
@@ -502,7 +502,7 @@ ztype||zkey := Base32GNS-Decode(zTLD)
        <t>
          The zTLD can be used as-is as a rightmost label in a GNS name.
          If an application wants to ensure DNS compatibility of the name,
-         it MAY also represent the zTLD as follows:
+         it <bcp14>MAY</bcp14> also represent the zTLD as follows:
          If the zTLD is less than or equal to 63 characters, it can
          be used as a zTLD as-is.
          If the zTLD is longer than 63 characters, the
@@ -512,7 +512,7 @@ ztype||zkey := Base32GNS-Decode(zTLD)
          the least significant bytes in the leftmost label of the resulting string. This allows the
          resolver to determine the ztype and zTLD length from the rightmost
          label and to subsequently determine how many labels the zTLD should span.
-         A GNS implementation MUST support the division of zTLD in DNS compatible
+         A GNS implementation <bcp14>MUST</bcp14> support the division of zTLD in DNS compatible
          label lengths.
          For example, assuming a zTLD of 130 characters, a viable division
          would be:
@@ -525,9 +525,9 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
     <section anchor="revocation" numbered="true" toc="default">
        <name>Zone Revocation</name>
        <t>
-         In order to revoke a zone key, a signed revocation message MUST be
+         In order to revoke a zone key, a signed revocation message <bcp14>MUST</bcp14> be
          published.
-         This message MUST be signed using the private key.
+         This message <bcp14>MUST</bcp14> be signed using the private key.
          The revocation message is broadcast to the network.
          The specification of the broadcast mechanism is out of scope for this
          document.
@@ -536,9 +536,9 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
          Alternatively, revocation messages could also be distributed via a
          distributed ledger or a trusted central server.
          To prevent
-         flooding attacks, the revocation message MUST contain a proof of work
+         flooding attacks, the revocation message <bcp14>MUST</bcp14> contain a proof of work
          (PoW).
-         The revocation message including the PoW MAY be calculated
+         The revocation message including the PoW <bcp14>MAY</bcp14> be calculated
          ahead of time to support timely revocation.
        </t>
        <t>
@@ -675,24 +675,24 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
          <dd>
            denotes the relative 64-bit time to live of the record in
            microseconds also in network byte order.
-           The field SHOULD be set to EPOCH * 1.1.
+           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 MAY be increased up to
+           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.
-           A verifier MAY discard a revocation without
+           A verifier <bcp14>MAY</bcp14> discard a revocation without
            checking the POW values or the signature if the TTL (in combination with TIMESTAMP)
            indicates that the revocation has already expired.
            The actual validity period of the
-           revocation MUST be determined by examining the leading zeroes in the
+           revocation <bcp14>MUST</bcp14> be determined by examining the leading zeroes in the
            POW values.
          </dd>
          <dt>POW_i</dt>
          <dd>
            The values calculated as part of the PoW, in network byte order.
-           Each POW_i MUST be unique in the set of POW values.
+           Each POW_i <bcp14>MUST</bcp14> be unique in the set of POW values.
            To facilitate fast verification
            of uniqueness, the POW values must be given in strictly
            monotonically increasing order in the message.
@@ -747,7 +747,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
          <dt>PURPOSE</dt>
          <dd>
            A 32-bit signature purpose flag.
-           The value of this field MUST be 3.
+           The value of this field <bcp14>MUST</bcp14> be 3.
            The value is encoded in network byte order.
            It defines the context in which
            the signature is created so that it cannot be reused in other parts
@@ -767,14 +767,14 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
          <dd>Field as defined in the revocation message above.</dd>
        </dl>
        <t>
-         In order to verify a revocation the following steps MUST be taken:
+         In order to verify a revocation the following steps <bcp14>MUST</bcp14> be taken:
        </t>
        <ol>
-         <li>The signature MUST be verified against the zone key.</li>
-         <li>The set of POW values MUST NOT contain duplicates which MUST be checked by verifying that the values are strictly monotonically increasing.</li>
+         <li>The signature <bcp14>MUST</bcp14> be verified against the zone key.</li>
+         <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 MUST be greater than and not equal to D.  Implementers
-         MUST NOT use an integer data type to calculate or represent D'.</li>
+         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>
        <li>
            The validity period of the revocation is calculated as
            (D'-D) * EPOCH * 1.1. The EPOCH is extended by
@@ -782,11 +782,11 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
            The validity period added on top of the TIMESTAMP yields the
            expiration date.
            Should the verifier calculate the validity and find that it differs from
-           the TTL field value, the verifier MUST continue and
+           the TTL field value, the verifier <bcp14>MUST</bcp14> continue and
            use the calculated value when forwarding the revocation.
          </li>
-         <li>The current time SHOULD be between TIMESTAMP and
-           TIMESTAMP + validity period. Implementations MAY 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>
 
@@ -795,7 +795,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
    <section anchor="rrecords" numbered="true" toc="default">
      <name>Resource Records</name>
      <t>
-       A GNS implementation SHOULD provide a mechanism to create and manage local
+       A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism to create and manage local
        zones as well as a persistence mechanism such as a database for resource
        records.
        A new local zone is established by selecting a zone type and creating a
@@ -859,11 +859,11 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
      </dl>
      <t>
        Flags indicate metadata surrounding the resource record.
-       Applications creating resource records MUST set all bits which are
+       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.
        If an application or implementation encounters a flag which it does not
-       recognize, it MUST be ignored.
+       recognize, it <bcp14>MUST</bcp14> be ignored.
        Any combination of the flags specified below are valid.
        <xref target="figure_flag"/>
        illustrates the flag distribution in the 16-bit flag field of a
@@ -882,12 +882,12 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
        <dd>
          If this flag is set, it indicates that processing is critical.
          Implementations that do not support the record type or are otherwise
-         unable to process the record MUST abort resolution upon encountering
+         unable to process the record <bcp14>MUST</bcp14> abort resolution upon encountering
          the record in the resolution process.
        </dd>
        <dt>SHADOW</dt>
        <dd>
-         If this flag is set, this record MUST be ignored by resolvers unless all (other)
+         If this flag is set, this record <bcp14>MUST</bcp14> be ignored by resolvers unless all (other)
          records of the same record type have expired.  Used to allow zone publishers to
          facilitate good performance when records change by allowing them to put future
          values of records into the storage.
@@ -906,14 +906,14 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
      <name>Zone Delegation Records</name>
      <t>
        This section defines the initial set of zone delegation record types.
-       Any implementation SHOULD support all zone types defined here and
-       MAY support any number of additional delegation records defined in
+       Any implementation <bcp14>SHOULD</bcp14> support all zone types defined here and
+       <bcp14>MAY</bcp14> support any number of additional delegation records defined in
        the GNU Name System Record Types registry (see <xref target="gana"/>).
        Not supporting some zone types will result in resolution failures in case
        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 MUST NOT be stored and published
+       Zone delegation records <bcp14>MUST</bcp14> NOT be stored and published
        under the apex label.
        A zone delegation record type value is the same as the respective ztype
        value.
@@ -921,8 +921,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 MUST have the CRTITICAL flag set.
-       A zone delegation record MUST be the only record under a label.
+       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.
        No other records are allowed.
      </t>
      <section anchor="gnsrecords_pkey" numbered="true" toc="default">
@@ -1227,13 +1227,13 @@ ZKDF-Public(zk,label):
   return zk'
            ]]></artwork>
          <t>
-           Implementers SHOULD employ a constant time scalar
+           Implementers <bcp14>SHOULD</bcp14> employ a constant time scalar
            multiplication for the constructions above to protect against
            timing attacks. Otherwise, timing attacks may leak private key
            material if an attacker can predict when a system starts the
            publication process.
            <!--Also, implementers
-           MUST ensure that the private key a is an ed25519 private key
+           <bcp14>MUST</bcp14> ensure that the private key a is an ed25519 private key
            and specifically that "a[0] &#38; 7 == 0" holds.-->
          </t>
          <t>
@@ -1256,7 +1256,7 @@ ZKDF-Public(zk,label):
            co-factor are integer operations.
          </t>
          <t>
-           The Sign(d,message) and Verify(zk,message,signature) procedures MUST
+           The Sign(d,message) and Verify(zk,message,signature) procedures <bcp14>MUST</bcp14>
            be implemented as defined in <xref target="RFC8032" />.
          </t>
          <t>
@@ -1265,7 +1265,7 @@ ZKDF-Public(zk,label):
            As the corresponding private key to the derived private scalar d'
            is not known, it is not possible to deterministically derive the
            signature part R according to <xref target="RFC8032" />.
-           Instead, signatures MUST be generated as follows for any given
+           Instead, signatures <bcp14>MUST</bcp14> be generated as follows for any given
            message and private zone key:
            A nonce is calculated from the highest 32 bytes of the
            expansion of the private key d and the blinding factor h.
@@ -1374,21 +1374,21 @@ S-Decrypt(zk,label,expiration,ciphertext):
      <name>Redirection Records</name>
      <t>
        Redirect records may be used to redirect resolution.
-       Any implementation SHOULD support all redirection record types defined here
-       and MAY support any number of additional redirection records defined in
+       Any implementation <bcp14>SHOULD</bcp14> support all redirection record types defined here
+       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 MUST have the CRTITICAL flag set.
-       Not supporting some record types MAY result in resolution failures.
-       This MAY BE a valid choice if some redirection record types have been
+       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
        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 MUST NOT be stored and published under the apex label.
+       Redirection records <bcp14>MUST</bcp14> NOT be stored and published under the apex label.
      </t>
      <section anchor="gnsrecords_rdr" numbered="true" toc="default">
        <name>REDIRECT</name>
        <t>
          A REDIRECT record is the GNS equivalent of a CNAME record in DNS.
-         A REDIRECT record MUST be the only record under a label.
+         A REDIRECT record <bcp14>MUST</bcp14> be the only record under a label.
          No other records are allowed.
          Details on processing of this record is defined in <xref target="redirect_processing"/>.
 
@@ -1424,8 +1424,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
          The resource record contains a DNS name for the resolver to continue with
          in DNS followed by a DNS server. Both names are in the format defined in
          <xref target="RFC1034" /> for DNS names.
-         There MAY be multiple GNS2DNS records under a label.
-         There MAY also be DNSSEC DS records or any other records used to
+         There <bcp14>MAY</bcp14> be multiple GNS2DNS records under a label.
+         There <bcp14>MAY</bcp14> also be DNSSEC DS records or any other records used to
          secure the connection with the DNS servers under the same label.
          No other record types are allowed in the same record set.
          A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsrecord"/>.</t>
@@ -1457,16 +1457,16 @@ S-Decrypt(zk,label,expiration,ciphertext):
            form or an IPv6 address in colon-hexadecimal form or a DNS name.
            It may also be a relative GNS name ending with a
            "+" as the rightmost label.
-           The implementation MUST check the string syntactically for
+           The implementation <bcp14>MUST</bcp14> check the string syntactically for
            an IP address in the respective notation before checking for a
            relative GNS name.
-           If all three checks fail, the name MUST be treated as a DNS name.
+           If all three checks fail, the name <bcp14>MUST</bcp14> be treated as a DNS name.
            The value is UTF-8 encoded and 0-terminated.
          </dd>
        </dl>
        <t>
          NOTE: If an application uses DNS names obtained from GNS2DNS records
-         in a DNS request they MUST first be converted to an IDNA compliant
+         in a DNS request they <bcp14>MUST</bcp14> first be converted to an IDNA compliant
          representation <xref target="RFC5890" />.
        </t>
      </section>
@@ -1475,7 +1475,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
        <name>Auxiliary Records</name>
        <t>
          This section defines the initial set of auxiliary GNS record types. Any
-         implementation SHOULD be able to process the specified record types
+         implementation <bcp14>SHOULD</bcp14> be able to process the specified record types
          according to <xref target="record_processing"/>.
        </t>
      <section anchor="gnsrecords_leho" numbered="true" toc="default">
@@ -1519,7 +1519,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
        </dl>
        <t>
          NOTE: If an application uses a LEHO value in an HTTP request header
-         (e.g. "Host:" header) it MUST be converted to an IDNA compliant representation
+         (e.g. "Host:" header) it <bcp14>MUST</bcp14> be converted to an IDNA compliant representation
          <xref target="RFC5890" />.
        </t>
      </section>
@@ -1531,7 +1531,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
          This is a suggestion to other zones what label to use when creating a
          delegation record (<xref target="gnsrecords_delegation" />) containing
          this zone key.
-         This record SHOULD only be stored under the apex label "@" but MAY be
+         This record <bcp14>SHOULD</bcp14> only be stored under the apex label "@" but <bcp14>MAY</bcp14> be
          returned with record sets under any label as a supplemental record.
          <xref target="nick_processing"/> details how a resolver must process
          supplemental and non-supplemental NICK records.
@@ -1552,7 +1552,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
          <dt>NICKNAME</dt>
          <dd>
            A UTF-8 string (which is not 0-terminated) representing the preferred
-           label of the zone. This string MUST be a valid GNS label.
+           label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS label.
          </dd>
        </dl>
      </section>
@@ -1624,9 +1624,9 @@ S-Decrypt(zk,label,expiration,ciphertext):
      <t>
        Any API which allows storing a value under a 512-bit key and retrieving
        one or more values from the key can be used by an implementation for record storage.
-       To be useful, the API MUST permit storing at least 176 byte values
+       To be useful, the API <bcp14>MUST</bcp14> permit storing at least 176 byte values
        to be able to support the defined zone delegation record encodings,
-       and SHOULD allow at least 1024 byte values.
+       and <bcp14>SHOULD</bcp14> allow at least 1024 byte values.
        In the following, it is assumed that an implementation realizes two
        procedures on top of a storage:
      </t>
@@ -1639,8 +1639,8 @@ 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 MUST NOT publish expired resource
-       records. Any GNS resolver MUST discard expired records returned from
+       the record. The GNS implementation <bcp14>MUST</bcp14> NOT publish expired resource
+       records. Any GNS resolver <bcp14>MUST</bcp14> discard expired records returned from
        the storage.
      </t>
      <t>
@@ -1654,7 +1654,7 @@ GET(key) -> value
        ensure query privacy (see <xref target="RFC8324"/>, Section 3.5).
        The storage key derivation and records
        block creation is specified in the following sections.
-       The implementation MUST use the PUT storage procedure in order to update
+       The implementation <bcp14>MUST</bcp14> use the PUT storage procedure in order to update
        the zone contents accordingly.
      </t>
      <section anchor="blinding" numbered="true" toc="default">
@@ -1685,8 +1685,8 @@ q := SHA-512 (ZKDF-Public(zk, label))
        <name>The Records Block</name>
        <t>
          GNS records are grouped by their labels and published as a single
-         block in the storage. The grouped record sets MAY be paired with any
-         number of supplemental records. Supplemental records MUST have the
+         block in the storage. The grouped record sets <bcp14>MAY</bcp14> be paired with any
+         number of supplemental records. Supplemental records <bcp14>MUST</bcp14> have the
          supplemental flag set (See <xref target="rrecords"/>).
          The contained resource records are encrypted using a symmetric
          encryption scheme.
@@ -1726,7 +1726,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
            A 32-bit value containing the length of the block in bytes.
            In network byte order.
            While a 32-bit value is used,
-           implementations MAY refuse to publish blocks beyond a certain
+           implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond a certain
            size significantly below 4 GB.
          </dd>
          <dt>ZONE TYPE</dt>
@@ -1751,9 +1751,9 @@ q := SHA-512 (ZKDF-Public(zk, label))
          <dt>EXPIRATION</dt>
          <dd>
            Specifies when the RRBLOCK expires and the encrypted block
-           SHOULD be removed from the storage and caches as it is likely stale.
-           However, applications MAY continue to use non-expired individual
-           records until they expire.  The value MUST be set to the
+           <bcp14>SHOULD</bcp14> be removed from the storage and caches as it is likely stale.
+           However, applications <bcp14>MAY</bcp14> continue to use non-expired individual
+           records until they expire.  The value <bcp14>MUST</bcp14> be set to the
            expiration time of the resource record contained within this block with the
            smallest expiration time.
            If a records block includes shadow records, then the maximum
@@ -1797,7 +1797,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
          <dt>PURPOSE</dt>
          <dd>
            A 32-bit signature purpose flag. The value of this
-           field MUST be 15.
+           field <bcp14>MUST</bcp14> be 15.
            The value is encoded in network byte order.
            It defines the context in which
            the signature is created so that it cannot be reused in other parts
@@ -1850,15 +1850,15 @@ q := SHA-512 (ZKDF-Public(zk, label))
          </dd>
          <dt>PADDING</dt>
          <dd>
-           When publishing an RDATA block, the implementation MUST ensure that
+           When publishing an RDATA block, the implementation <bcp14>MUST</bcp14> ensure that
            the size of the RDATA is a power of two
-           using the padding field. The field MUST be set to zero and MUST be
+           using the padding field. The field <bcp14>MUST</bcp14> be set to zero and <bcp14>MUST</bcp14> be
            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 MUST NOT
+           Note that a record set with a delegation record <bcp14>MUST</bcp14> NOT
            contain other records. If other records are encountered, the whole
-           record block MUST be discarded.
+           record block <bcp14>MUST</bcp14> be discarded.
          </dd>
        </dl>
      </section>
@@ -1869,19 +1869,19 @@ q := SHA-512 (ZKDF-Public(zk, label))
        Names in GNS are resolved by recursively querying the record storage.
        Recursive in this context means that a resolver does not provide
        intermediate results for a query.
-       Instead, it MUST respond to a resolution request with either the
+       Instead, it <bcp14>MUST</bcp14> respond to a resolution request with either the
        requested resource record or an error message in case the resolution
        fails.
        The following sections detail how resolution is initiated and each
        iteration in the resolution is processed.
      </t>
      <t>
-       The application MAY provide a desired record type to the resolver.
+       The application <bcp14>MAY</bcp14> provide a desired record type to the resolver.
        The desired record type is used to guide processing.
        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 MUST NOT filter results according to the desired
+       The resolver implementation <bcp14>MUST</bcp14> NOT filter results according to the desired
        record type.
        Filtering of record sets is typically done by the application.
      </t>
@@ -1903,19 +1903,19 @@ q := SHA-512 (ZKDF-Public(zk, label))
          For names ending with a zTLD the start zone is explicitly given in the
          suffix of the name to resolve.
          In order to ensure uniqueness of names with zTLDs any
-         implementation MUST use the given zone as start zone.
-         An implementation MUST first try to interpret the rightmost label of
+         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"/>).
          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 MUST continue with finding a local suffix-to-zone
+         start zone discovery <bcp14>MUST</bcp14> continue with finding a local suffix-to-zone
          mapping.
          If a valid ztype can be found in the rightmost label, the
-         implementation MUST try to synthesize and decode the zTLD to retrieve
+         implementation <bcp14>MUST</bcp14> try to synthesize and decode the zTLD to retrieve
          the start zone key according to <xref target="zTLD"/>.
          If the zTLD cannot be synthesized or decoded, the resolution of
          the name fails and an error is returned to the application.
-         Otherwise, the zone key MUST be used as the start zone:
+         Otherwise, the zone key <bcp14>MUST</bcp14> be used as the start zone:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Example name: www.example.<zTLD>
@@ -1923,16 +1923,16 @@ Example name: www.example.<zTLD>
 => Name to resolve from start zone: www.example
          ]]></artwork>
        <t>
-         For names not ending with a zTLD the resolver MUST determine the start
+         For names not ending with a zTLD the resolver <bcp14>MUST</bcp14> determine the start
          zone through a local suffix-to-zone mapping.
-         Suffix-to-zone mappings MUST be configurable through a local
+         Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a local
          configuration file or database by the user or system administrator.
-         A suffix MAY consist of multiple GNS labels concatenated with a
+         A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels concatenated with a
          label separator.
          If multiple suffixes match the name to resolve, the longest
-         matching suffix MUST be used. The suffix length of two results
-         MUST NOT be equal. This indicates a misconfiguration and the
-         implementation MUST return an error.
+         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
+         implementation <bcp14>MUST</bcp14> return an error.
          The following is a non-normative example mapping of start zones:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1946,10 +1946,10 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
 => Name to resolve from start zone: www
          ]]></artwork>
        <t>
-         The process given above MAY be supplemented with other mechanisms if
+         The process given above <bcp14>MAY</bcp14> be supplemented with other mechanisms if
          the particular application requires a different process.
-         If no start zone can be discovered, resolution MUST fail and an
-         error MUST be returned to the application.
+         If no start zone can be discovered, resolution <bcp14>MUST</bcp14> fail and an
+         error <bcp14>MUST</bcp14> be returned to the application.
        </t>
      </section>
        <section anchor="recursion" numbered="true" toc="default">
@@ -1973,11 +1973,11 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
          </ol>
          <t>
            Upon receiving the RRBLOCK from the storage, as part of verifying the
-           provided signature, the resolver MUST check that the SHA-512 hash of the
+           provided signature, the resolver <bcp14>MUST</bcp14> check that the SHA-512 hash of the
            derived authoritative zone key zk' from the RRBLOCK matches the query q
            and that the block is not yet expired.
-           If the signature does not match or the block is expired, the RRBLOCK MUST
-           be ignored and, if applicable, the storage lookup GET(q) MUST continue to
+           If the signature does not match or the block is expired, the RRBLOCK <bcp14>MUST</bcp14>
+           be ignored and, if applicable, the storage lookup GET(q) <bcp14>MUST</bcp14> continue to
            look for other RRBLOCKs.
          </t>
        </section>
@@ -1987,14 +1987,14 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
            Record processing occurs once a well-formed block has been decrypted.
            In record processing, only the valid records obtained are considered.
            To filter records by validity, the resolver
-           MUST at least check the expiration time and the FLAGS field of the
+           <bcp14>MUST</bcp14> at least check the expiration time and the FLAGS field of the
            respective record.  In particular, SHADOW and
            SUPPLEMENTAL flags may exclude the record from being considered.
            If the resolver encounters a record with the CRITICAL flag set and
-           does not support the record type the resolution MUST be aborted
-           and an error MUST be returned. The information that the critical
-           record could not be processed SHOULD be returned in the error
-           description. The implementation MAY choose not to return the reason for the failure,
+           does not support the record type the resolution <bcp14>MUST</bcp14> be aborted
+           and an error <bcp14>MUST</bcp14> be returned. The information that the critical
+           record could not be processed <bcp14>SHOULD</bcp14> be returned in the error
+           description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
            merely complicating troubleshooting for the user.
            The next steps depend on the context of the name that is beging
            resolved:
@@ -2031,13 +2031,13 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
            Case 5:
            If the remainder of the name to resolve is empty
            the record set is the final result.
-           If any NICK records are in the final result set, it MUST be
+           If any NICK records are in the final result set, it <bcp14>MUST</bcp14> be
            processed according to <xref target="nick_processing" />.
            Otherwise, the final result set is returned.
          </li>
          <li>
            Finally, if none of the above is applicable resolution fails and the
-           resolver MUST return an empty record set.
+           resolver <bcp14>MUST</bcp14> return an empty record set.
          </li>
         </ul>
          <section anchor="redirect_processing" numbered="true" toc="default">
@@ -2053,14 +2053,14 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
              default operating system name resolution process.
              This may in turn trigger a GNS name resolution process depending
              on the system configuration.
-             In case resolution continues in DNS, the name MUST first be
+             In case resolution continues in DNS, the name <bcp14>MUST</bcp14> first be
              converted to an IDNA compliant representation <xref target="RFC5890" />.
            </t>
            <t>
-             In order to prevent infinite loops, the resolver MUST
+             In order to prevent infinite loops, the resolver <bcp14>MUST</bcp14>
              implement loop detections or limit the number of recursive
              resolution steps.
-             The loop detection MUST be effective even
+             The loop detection <bcp14>MUST</bcp14> be effective even
              if a REDIRECT found in GNS triggers subsequent GNS lookups via
              the default operating system name resolution process.
            </t>
@@ -2077,7 +2077,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
              IP addresses of the specified DNS name servers.
              The DNS name may have to be converted to an IDNA compliant
              representation <xref target="RFC5890" /> for resolution in DNS.
-             GNS2DNS records MAY
+             GNS2DNS records <bcp14>MAY</bcp14>
              contain numeric IPv4 or IPv6 addresses, allowing the resolver to
              skip this step.
              The DNS server names may themselves be names in GNS or DNS.
@@ -2090,16 +2090,16 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
            </t>
            <t>
              Multiple GNS2DNS records may be stored under the same label,
-             in which case the resolver MUST try all of them.
-             The resolver MAY try them in any order or even in parallel.
-             If multiple GNS2DNS records are present, the DNS name MUST be
+             in which case the resolver <bcp14>MUST</bcp14> try all of them.
+             The resolver <bcp14>MAY</bcp14> try them in any order or even in parallel.
+             If multiple GNS2DNS records are present, the DNS name <bcp14>MUST</bcp14> be
              identical for all of them, if not the resolution fails and an
-             appropriate error is SHOULD be returned to the application.
+             appropriate error is <bcp14>SHOULD</bcp14> be returned to the application.
            </t>
            <t>
              If there are DNSSEC DS records or any other records used to
              secure the connection with the DNS servers stored under the label,
-             the DNS resolver SHOULD use them to secure the connection with
+             the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the connection with
              the DNS server.
            </t>
            <t>
@@ -2109,39 +2109,39 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
              resolved by querying the DNS name server(s).
              The synthesized name may have to be converted to an IDNA compliant
              representation <xref target="RFC5890" /> for resolution in DNS.
-             If such a conversion is not possible, the resolution MUST be aborted
-             and an error MUST be returned. The information that the critical
-             record could not be processed SHOULD be returned in the error
-             description. The implementation MAY choose not to return the reason for the failure,
+             If such a conversion is not possible, the resolution <bcp14>MUST</bcp14> be aborted
+             and an error <bcp14>MUST</bcp14> be returned. The information that the critical
+             record could not be processed <bcp14>SHOULD</bcp14> be returned in the error
+             description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
              merely complicating troubleshooting for the user.
            </t>
            <t>
              As the DNS servers
-             specified are possibly authoritative DNS servers, the GNS resolver MUST
-             support recursive DNS resolution and MUST NOT delegate this to the
+             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
              authoritative DNS servers.
              The first successful recursive name resolution result
              is returned to the application.
-             In addition, the resolver SHOULD return the queried DNS name as a
+             In addition, the resolver <bcp14>SHOULD</bcp14> return the queried DNS name as a
              supplemental LEHO record (see <xref target="gnsrecords_leho" />) with a
              relative expiration time of one hour.
            </t>
            <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 MUST NOT
+             The (possibly recursive) resolution of the DNS name <bcp14>MUST</bcp14> NOT
              delegate back into GNS and should only follow the DNS specifications.
-             For example, names contained in DNS CNAME records MUST NOT be
+             For example, names contained in DNS CNAME records <bcp14>MUST</bcp14> NOT be
              interpreted as GNS names.
            </t>
            <t>
-             GNS resolvers SHOULD offer a configuration
+             GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration
              option to disable DNS processing to avoid information leakage
              and provide a consistent security profile for all name resolutions.
              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 label and a GNS2DNS record
-             is explicitly requested by the application, such records MUST
+             is explicitly requested by the application, such records <bcp14>MUST</bcp14>
              still be returned, even if DNS support is disabled by the
              GNS resolver configuration.
            </t>
@@ -2168,20 +2168,20 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
              GNS zone specified in the delegation record.
            </t>
            <t>
-             Whenever a resolver encounters a new GNS zone, it MUST
+             Whenever a resolver encounters a new GNS zone, it <bcp14>MUST</bcp14>
              check against the local revocation list whether the respective
              zone key has been revoked. If the zone key was revoked, the
-             resolution MUST fail with an empty result set.
+             resolution <bcp14>MUST</bcp14> fail with an empty result set.
            </t>
            <t>
-             Implementations MUST NOT allow multiple different zone
+             Implementations <bcp14>MUST</bcp14> NOT allow multiple different zone
              delegations under a single label.
-             Implementations MAY support any subset of ztypes.
+             Implementations <bcp14>MAY</bcp14> support any subset of ztypes.
              Handling of
-             Implementations MUST NOT process zone delegation for the apex
+             Implementations <bcp14>MUST</bcp14> NOT process zone delegation for the apex
              label "@". Upon encountering a zone delegation record under
-             this label, resolution fails and an error MUST be returned. The
-             implementation MAY choose not to return the reason for the failure,
+             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,
              merely impacting troubleshooting information for the user.
            </t>
            <t>
@@ -2250,7 +2250,7 @@ NICK: john (Supplemental)
        <name>Internationalization and Character Encoding</name>
        <t>
          All names in GNS are encoded in UTF-8 <xref target="RFC3629" />.
-         Labels MUST be canonicalized using
+         Labels <bcp14>MUST</bcp14> be canonicalized using
          Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
          This does not include any DNS names found in DNS records, such as CNAME
          record data, which is internationalized through the IDNA specifications
@@ -2263,13 +2263,13 @@ NICK: john (Supplemental)
          <name>Availability</name>
          <t>
            In order to ensure availability of records beyond their
-           absolute expiration times, implementations MAY allow to locally
+           absolute expiration times, implementations <bcp14>MAY</bcp14> allow to locally
            define relative expiration time values of records.
            Records can then be published recurringly with updated
            absolute expiration times by the implementation.
          </t>
          <t>
-           Implementations MAY allow users to manage private records in
+           Implementations <bcp14>MAY</bcp14> allow users to manage private records in
            their zones that are not published in the storage.
            Private records are considered just like
            regular records when resolving labels in local zones,
@@ -2284,11 +2284,11 @@ NICK: john (Supplemental)
            with those algorithms.  The security also depends on the engineering
            of the protocol used by the system to ensure that there are no
            non-cryptographic ways to bypass the security of the overall system.
-           This is why developers of applications managing GNS zones SHOULD
+           This is why developers of applications managing GNS zones <bcp14>SHOULD</bcp14>
            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 MUST NOT leave
+           understand cryptography, the application developer <bcp14>MUST</bcp14> NOT leave
            the ztype selection of new zones to end users.
          </t>
          <t>
@@ -2342,24 +2342,24 @@ NICK: john (Supplemental)
            ensured because each time a block is published into the storage, its IV is
            unique as the expiration time is calculated dynamically and increases
            monotonically with the system time. Still,
-           an implementation MUST ensure that when relative expiration times
-           are decreased, the expiration time of the next record block MUST
+           an implementation <bcp14>MUST</bcp14> ensure that when relative expiration times
+           are decreased, the expiration time of the next record block <bcp14>MUST</bcp14>
            be after the last published block.
            For records where an absolute expiration time is used, the implementation
-           MUST ensure that the expiration time is always increased when the record
+           <bcp14>MUST</bcp14> ensure that the expiration time is always increased when the record
            data changes. For example, the expiration time on the wire may be increased
            by a single microsecond even if the user did not request a change.
            In case of deletion of all resource records under a label, the
-           implementation MUST keep track of the last absolute expiration time
-           of the last published resource block.  Implementations MAY define 
+           implementation <bcp14>MUST</bcp14> keep track of the last absolute expiration time
+           of the last published resource block.  Implementations <bcp14>MAY</bcp14> define 
            and use a special record type as a tombstone that preserves the last
-           absolute expiration time, but then MUST take care to not publish a
+           absolute expiration time, but then <bcp14>MUST</bcp14> take care to not publish a
            block with this record.
            When new records are added under this label later, the implementation
-           MUST ensure that the expiration times are after the last published
+           <bcp14>MUST</bcp14> ensure that the expiration times are after the last published
            block.
            Finally, in order to ensure monotonically increasing expiration times
-           the implementation MUST keep a local record of the last time obtained
+           the implementation <bcp14>MUST</bcp14> keep a local record of the last time obtained
            from the system clock, so as to construct a monotonic clock in case
            the system clock jumps backwards.
          </t>
@@ -2551,10 +2551,10 @@ NICK: john (Supplemental)
          gns-registry@gnunet.org.
        </t>
        <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
+         Any request <bcp14>MUST</bcp14> contain a unique name and a point of contact.
+         The contact information <bcp14>MAY</bcp14> be added to the registry given the consent
          of the requester.
-         The request MAY optionally also contain relevant references as well
+         The request <bcp14>MAY</bcp14> optionally also contain relevant references as well
          as a descriptive comment as defined above.
        </t>
        <t>
@@ -2950,7 +2950,7 @@ Purpose | Name            | References | Comment
          If the bit length of the byte string to encode is not a multiple of 5
          it is padded to the next multiple with zeroes.
          In order to further increase tolerance for failures in character
-         recognition, the letter "U" MUST be decoded to the same value as the
+         recognition, the letter "U" <bcp14>MUST</bcp14> be decoded to the same value as the
          letter "V" in Base32GNS.
        </t>
        <figure anchor="CrockfordB32Encode" title="The Base32GNS Alphabet Including the Additional U Encode Symbol.">