[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] 02/02: figure titles
|
From: |
gnunet |
|
Subject: |
[lsd0001] 02/02: figure titles |
|
Date: |
Wed, 16 Feb 2022 18:26:54 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
commit d282c0dfe73f63fa48f40be510bd3ffe4f9077d7
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Feb 16 18:26:47 2022 +0100
figure titles
---
draft-schanzen-gns.xml | 76 +++++++++++++++-----------------------------------
1 file changed, 23 insertions(+), 53 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 94c1574..09efdde 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -432,7 +432,7 @@
</dl>
<section anchor="zTLD" numbered="true" toc="default">
<name>Zone Top-Level Domain</name>
- <figure anchor="figure_zid">
+ <figure anchor="figure_zid" title="The decoded binary representation of
the zTLD">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -442,7 +442,6 @@
/ /
]]></artwork>
</figure>
- <t>The decoded binary representation of the zTLD</t>
<t>
The zTLD is the Zone Top-Level Domain.
It is a string which encodes the zone type and zone key into a domain
name.
@@ -535,7 +534,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<xref target="figure_revocation"/> illustrates the format
of the data "P" on which the PoW is calculated.
</t>
- <figure anchor="figure_revocation">
+ <figure anchor="figure_revocation" title="The Format of the PoW Data.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -550,7 +549,6 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The Format of the PoW Data.</t>
<dl>
<dt>POW</dt>
<dd>
@@ -604,7 +602,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
The revocation message wire format is illustrated in
<xref target="figure_revocationdata"/>.
</t>
- <figure anchor="figure_revocationdata">
+ <figure anchor="figure_revocationdata" title="The Revocation Message
Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -630,7 +628,6 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The Revocation Message Wire Format.</t>
<dl>
<dt>TIMESTAMP</dt>
<dd>
@@ -683,7 +680,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
The wire format is illustrated
in <xref target="figure_revsigwithpseudo"/>.
</t>
- <figure anchor="figure_revsigwithpseudo">
+ <figure anchor="figure_revsigwithpseudo" title="The Wire Format of the
Revocation Data for Signing.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -698,7 +695,6 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The Wire Format of the Revocation Data for Signing.</t>
<dl>
<dt>SIZE</dt>
<dd>
@@ -768,7 +764,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
The resource record format is defined in
<xref target="figure_gnsrecord"/>.
</t>
- <figure anchor="figure_gnsrecord">
+ <figure anchor="figure_gnsrecord" title="The Resource Record Wire
Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -781,7 +777,6 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
/ /
]]></artwork>
</figure>
- <t>The Resource Record Wire Format.</t>
<dl>
<dt>EXPIRATION</dt>
<dd>
@@ -827,7 +822,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
illustrates the flag distribution in the 16-bit flag field of a
resource record:
</t>
- <figure anchor="figure_flag">
+ <figure anchor="figure_flag" title="The Resource Record Flag Wire
Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 13 14 15 16
+--------...+-------------+-------+---------+
@@ -835,7 +830,6 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
+--------...+-------------+-------+---------+
]]></artwork>
</figure>
- <t>The Resource Record Flag Wire Format.</t>
<dl>
<dt>CRITICAL</dt>
<dd>
@@ -890,7 +884,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
In GNS, a delegation of a label to a zone of type "PKEY" is
represented through a PKEY record. The PKEY DATA entry wire format
can be found in <xref target="figure_pkeyrecord"/>.
</t>
- <figure anchor="figure_pkeyrecord">
+ <figure anchor="figure_pkeyrecord" title="The PKEY Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -901,7 +895,6 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The PKEY Wire Format.</t>
<dl>
<dt>PUBLIC KEY</dt>
<dd>
@@ -1013,7 +1006,7 @@ VerifyDerived(zk,label,message,signature):
The S-Encrypt() and S-Decrypt() functions use AES in counter mode
as defined in <xref target="MODES" /> (CTR-AES-256):
</t>
- <figure anchor="figure_senc_pkey">
+ <figure anchor="figure_senc_pkey" title="The PKEY S-Encrypt Procedure.">
<artwork name="" type="" align="left" alt=""><![CDATA[
S-Encrypt(zk,label,expiration,plaintext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
@@ -1024,8 +1017,7 @@ S-Encrypt(zk,label,expiration,plaintext):
return CTR-AES256(K, IV, plaintext)
]]></artwork>
</figure>
- <t>The PKEY S-Encrypt Procedure.</t>
- <figure anchor="figure_sdec_pkey">
+ <figure anchor="figure_sdec_pkey" title="The PKEY S-Decrypt Procedure.">
<artwork name="" type="" align="left" alt=""><![CDATA[
S-Decrypt(zk,label,expiration,ciphertext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
@@ -1036,7 +1028,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
return CTR-AES256(K, IV, ciphertext)
]]></artwork>
</figure>
- <t>The PKEY S-Decrypt Procedure.</t>
<t>
The key K and counter IV are derived from
the record label and the zone key zk using a hash-based key
@@ -1058,7 +1049,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
The resulting counter (IV) wire format can be found in
<xref target="figure_hkdf_ivs_pkey"/>.
</t>
- <figure anchor="figure_hkdf_ivs_pkey">
+ <figure anchor="figure_hkdf_ivs_pkey" title="The Block Counter Wire
Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32
+-----+-----+-----+-----+
@@ -1071,7 +1062,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The Block Counter Wire Format.</t>
</section>
<section anchor="gnsrecords_edkey" numbered="true" toc="default">
<name>EDKEY</name>
@@ -1081,7 +1071,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
The EDKEY DATA entry wire format
is illustrated in <xref target="figure_edkeyrecord"/>.
</t>
- <figure anchor="figure_edkeyrecord">
+ <figure anchor="figure_edkeyrecord" title="The EDKEY DATA Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1092,7 +1082,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The EDKEY DATA Wire Format.</t>
<dl>
<dt>PUBLIC KEY</dt>
<dd>
@@ -1328,7 +1317,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
The resulting counter (IV) wire format is illustrated in
<xref target="figure_hkdf_ivs_edkey"/>.
</t>
- <figure anchor="figure_hkdf_ivs_edkey">
+ <figure anchor="figure_hkdf_ivs_edkey" title="The Counter Block
Initialization Vector.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32
+-----+-----+-----+-----+
@@ -1342,7 +1331,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The Counter Block Initialization Vector</t>
</section>
</section>
<section anchor="gnsrecords_redirect" numbered="true" toc="default">
@@ -1369,7 +1357,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
A REDIRECT DATA entry is illustrated in <xref
target="figure_redirectrecord"/>.
</t>
- <figure anchor="figure_redirectrecord">
+ <figure anchor="figure_redirectrecord" title="The REDIRECT DATA Wire
Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1380,7 +1368,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t> The REDIRECT DATA Wire Format</t>
<dl>
<dt>REDIRECT NAME</dt>
<dd>
@@ -1404,7 +1391,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
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>
- <figure anchor="figure_gns2dnsrecord">
+ <figure anchor="figure_gns2dnsrecord" title="The GNS2DNS DATA Wire
Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1420,7 +1407,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
+-----------------------------------------------+
]]></artwork>
</figure>
- <t> The GNS2DNS DATA Wire Format</t>
<dl>
<dt>DNS NAME</dt>
<dd>
@@ -1473,7 +1459,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
A LEHO resource record is expected to be found together in a single
resource record with an IPv4 or IPv6 address.
A LEHO DATA entry is illustrated in <xref
target="figure_lehorecord"/>.</t>
- <figure anchor="figure_lehorecord">
+ <figure anchor="figure_lehorecord" title="The LEHO DATA Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1484,7 +1470,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t> The LEHO DATA Wire Format.</t>
<dl>
<dt>LEGACY HOSTNAME</dt>
<dd>
@@ -1511,7 +1496,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
supplemental and non-supplemental NICK records.
A NICK DATA entry is illustrated in <xref
target="figure_nickrecord"/>.
</t>
- <figure anchor="figure_nickrecord">
+ <figure anchor="figure_nickrecord" title="The NICK DATA Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1522,7 +1507,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The NICK DATA Wire Format.</t>
<dl>
<dt>NICKNAME</dt>
<dd>
@@ -1554,7 +1538,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
For reference, see also <xref target="RFC2782" />.
A BOX DATA entry is illustrated in <xref
target="figure_boxrecord"/>.
</t>
- <figure anchor="figure_boxrecord">
+ <figure anchor="figure_boxrecord" title="The BOX DATA Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1567,14 +1551,9 @@ S-Decrypt(zk,label,expiration,ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The BOX DATA Wire Format.</t>
<dl>
<dt>PROTO</dt>
<dd>
- <!-- FIXME: Help Christian this is all wrong.
- RFC6895 is DNS. Also: SVC what are possible numbers?
- Changed to 5237. Correct? SVC is still unknown.
- -->
the 16-bit protocol number, e.g. 6 for tcp.
Note that values
below 2^8 are reserved for allocation via IANA <xref
target="RFC5237" />,
@@ -1679,7 +1658,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
The GNS RRBLOCK wire format is illustrated in
<xref target="figure_record_block"/>.
</t>
- <figure anchor="figure_record_block">
+ <figure anchor="figure_record_block" title="The RRBLOCK Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1702,7 +1681,6 @@ q := SHA-512 (ZKDF-Public(zk, label))
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The RRBLOCK Wire Format.</t>
<dl>
<dt>SIZE</dt>
<dd>
@@ -1756,7 +1734,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
The wire format is illustrated
in <xref target="figure_rrsigwithpseudo"/>.
</t>
- <figure anchor="figure_rrsigwithpseudo">
+ <figure anchor="figure_rrsigwithpseudo" title="The Wire Format used for
creating the signature of the RRBLOCK.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1770,7 +1748,6 @@ q := SHA-512 (ZKDF-Public(zk, label))
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The Wire Format used for creating the signature of the RRBLOCK.</t>
<dl>
<dt>SIZE</dt>
<dd>
@@ -1802,7 +1779,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
The wire format of the RDATA is illustrated in
<xref target="figure_rdata"/>.
</t>
- <figure anchor="figure_rdata">
+ <figure anchor="figure_rdata" title="The RDATA Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1825,7 +1802,6 @@ q := SHA-512 (ZKDF-Public(zk, label))
/ /
]]></artwork>
</figure>
- <t>The RDATA Wire Format.</t>
<dl>
<dt>EXPIRATION, SIZE, TYPE, FLAGS and DATA</dt>
<dd>
@@ -2540,7 +2516,7 @@ NICK: john (Supplemental)
GANA is requested to populate this registry as listed in
<xref target="figure_rrtypenums"/>.
</t>
- <figure anchor="figure_rrtypenums">
+ <figure anchor="figure_rrtypenums" title="The GANA Resource Record
Registry.">
<artwork name="" type="" align="left" alt=""><![CDATA[
Number | Name | Contact | References | Comment
-------+---------+---------+------------+-------------------------
@@ -2553,12 +2529,11 @@ Number | Name | Contact | References | Comment
65556 | EDKEY | N/A | [This.I-D] | GNS zone delegation (EDKEY)
]]></artwork>
</figure>
- <t>The GANA Resource Record Registry.</t>
<t>
GANA is requested to amend the "GNUnet Signature Purpose" registry
as illustrated in <xref target="figure_purposenums"/>.
</t>
- <figure anchor="figure_purposenums">
+ <figure anchor="figure_purposenums" title="Requested Changes in the
GANA GNUnet Signature Purpose Registry.">
<artwork name="" type="" align="left" alt=""><![CDATA[
Purpose | Name | References | Comment
--------+-----------------+------------+--------------------------
@@ -2566,7 +2541,6 @@ Purpose | Name | References | Comment
15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature
]]></artwork>
</figure>
- <t>Requested Changes in the GANA GNUnet Signature Purpose Registry.</t>
</section>
<!-- gana -->
<section>
@@ -2922,7 +2896,7 @@ Purpose | Name | References | Comment
recognition, the letter "U" MUST be decoded to the same value as the
letter "V" in Base32GNS.
</t>
- <figure anchor="CrockfordB32Encode">
+ <figure anchor="CrockfordB32Encode" title="The Base32GNS Alphabet
Including the Additional U Encode Symbol.">
<artwork name="" type="" align="left" alt=""><![CDATA[
Symbol Decode Encode
Value Symbol Symbol
@@ -2960,10 +2934,6 @@ Value Symbol Symbol
31 Z z Z
]]></artwork>
</figure>
- <t>
- The Base32GNS Alphabet Including the Additional U Encode Symbol.
- </t>
-
</section>
<section>
<name>Test Vectors</name>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.