lsd0001

commit 9d12216f06c909d6dca264d32b225c6718807d41
parent d3c2fff7cb531745e1345e89cb7f5acf2a8a0f71
Author: Christian Grothoff <christian@grothoff.org>
Date:   Tue,  1 Feb 2022 15:53:16 +0100

use message, this is NOT an object

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

1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -502,15 +502,15 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          resolution MUST fail with an empty result set.
        </t>
        <t>
-         In order to revoke a zone key, a signed revocation object MUST be
+         In order to revoke a zone key, a signed revocation message MUST be
          published.
-         This object MUST be signed using the private key.
-         The revocation object is broadcast to the network.
+         This message MUST be signed using the private key.
+         The revocation message is broadcast to the network.
          The specification of the broadcast mechanism is out of scope of this
          document.
          A possible broadcast mechanism for efficient flooding in a distributed
          network is implemented in <xref target="GNUnet"/>.
-         Alternatively, revocation objects could also be distributed via a
+         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
@@ -723,7 +723,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
            The 32-bit zone type corresponding to the zone key.
          </dd>
          <dt>ZONE KEY / TIMESTAMP</dt>
-         <dd>Both values as defined in the revocation data object above.</dd>
+         <dd>Both values as defined in the revocation message above.</dd>
        </dl>
        <t>
          In order to verify a revocation the following steps must be taken,