[lsd0001] branch master updated: more revocationing

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 98b6997  more revocationing
98b6997 is described below

commit 98b6997bda240d4deb9e8f65244e2352c6200019
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Feb 21 15:48:54 2022 +0100

    more revocationing
---
 draft-schanzen-gns.xml | 60 ++++++++++++++++++++++++++++++++------------------
 1 file changed, 38 insertions(+), 22 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 147a94c..a02251c 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -676,13 +676,6 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
            <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 <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 <bcp14>MUST</bcp14> be determined by examining the 
leading zeroes in the
-           POW values.
          </dd>
          <dt>POW_i</dt>
          <dd>
@@ -770,22 +763,45 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
          <li>The average number of leading zeroes D' resulting from the 
provided
          POW values <bcp14>MUST</bcp14> be greater than and not equal to D.  
Implementers
          <bcp14>MUST NOT</bcp14> 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
-           10% in order to deal with unsynchronized clocks.
-           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 <bcp14>MUST</bcp14> continue and
-           use the calculated value when forwarding the revocation.
-         </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>
+       <t>
+         The TTL field is informational.
+         A revocation <bcp14>MAY</bcp14> be discarded 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 <bcp14>MUST</bcp14> be determined by examining the leading
+         zeroes in the POW values.
+       </t>
+       <t>
+         The validity period of the revocation is calculated as
+         (D'-D) * EPOCH * 1.1. The EPOCH is extended by
+         10% in order to deal with unsynchronized clocks.
+         The validity period added on top of the TIMESTAMP yields the
+         expiration date.
+         If the current time is after the expiration date, the
+         revocation is considered stale but may still be otherwise
+         considered valid.
+         Stale revocations <bcp14>MAY</bcp14> be discarded.
+       </t>
+       <t>
+         Verified revocations <bcp14>SHOULD</bcp14> be cached locally.
+         An implementation without a local revocations cache will be unable
+         to effectively process zone revocations.
+         The implementation <bcp14>MAY</bcp14> evict revocations from the local
+         cache at any time using an eviction strategy.
+       </t>
+       <t>
+         Implementations <bcp14>MUST</bcp14> forward received revocations to
+         other peers if they are valid and not stale.
+         Should the calculated validity period differs from the TTL field 
value,
+         the calculated value <bcp14>MUST</bcp14> be used as TTL field value
+         when forwarding the revocation message.
+         Any valid revocation MAY be used during delegation record
+         processing (<xref target="delegation_processing"/>).
+         Implementations <bcp14>MAY</bcp14> use stale but otherwise valid
+         revocations and <bcp14>MAY</bcp14> forward them to other peers.
+       </t>
      </section>
 
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.