commit bb51da0d5d12a1bb213dece7aa9e8cd74c1c710b parent 98b6997bda240d4deb9e8f65244e2352c6200019 Author: Martin Schanzenbach <schanzen@gnunet.org> Date: Mon, 21 Feb 2022 16:03:10 +0100 more revocationing #2 Diffstat:
| M | draft-schanzen-gns.xml | | | 18 | +++++++++--------- |
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml @@ -785,22 +785,22 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62] 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. + Verified revocations <bcp14>MUST</bcp14> be stored locally. + The implementation <bcp14>MAY</bcp14> evict stale revocations from the + local store at any time. </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, + Should the calculated validity period differ 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 + Any valid revocation MAY be considered 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. + Systems may disagree on the current time, so implementations + <bcp14>MAY</bcp14> use stale but otherwise valid + revocations but <bcp14>SHOULD NOT</bcp14> forward them to other peers. + Forwarded stale revocations may be discarded. </t> </section>