more revocationing

1 files 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>