add prop303 for making protovers required

1 files changed, 62 insertions, 0 deletions

diff --git a/proposals/303-protover-removal-policy.txt b/proposals/303-protover-removal-policy.txt
new file mode 100644
index 0000000..f6f30a8
--- /dev/null
+++ b/proposals/303-protover-removal-policy.txt
@@ -0,0 +1,62 @@
+Filename: 303-protover-removal-policy.txt
+Title: When and how to remove support for protocol versions
+Author: Nick Mathewson
+Created: 21 May 2019
+Status: Draft
+
+1. Background
+
+   With proposal 264, added support for "subprotocol versions" -- a
+   means to declare which features are required for participation in the
+   Tor network.  We also created a mechanism (refined later in proposal
+   297) for telling Tor clients and relays that they cannot participate
+   effectively in the Tor network, and they need to shut down.
+
+   In this document, we describe a policy according to which these
+   decisions should be made in practice.
+
+2. Recommending features (for clients and relays)
+
+   A subprotocol version SHOULD become recommended soon after all
+   release series that did not provide it become unsupported (within a
+   month or so).
+
+   For example, the current oldest LTS release series is 0.2.9; when it
+   becomes unsupported in 2020, the oldest supported release series will
+   be 0.3.5.  Suppose that 0.2.9 supports a subprotocol Cupcake=1, and
+   that all stable 0.3.5.x versions support Cupcake=1-3.  Around one
+   month after the end of 0.2.9 support, Cupcake=3 should become a
+   _recommended_ protocol for clients and relays.
+
+   Additionally, a feature can become _recommended_ because of security
+   reasons.  If we believe that it is a terrible idea to run an old
+   protocol, we can make it _recommended_ for relays or clients or both.
+   We should not do this lightly, since it will be annoying.
+
+3. Requiring features (for relays)
+
+   We regularly update the directory authorities to require relays to
+   run certain versions of Tor or later.  We generally do this after a
+   short outreach campaign to get as many relays as possible to upgrade.
+
+   We MAY make a feature required for relays one month after every
+   version without it is obsolete and unsupported, though it is better
+   to wait three months if possible.
+
+   We SHOULD make a feature required for relays within 12 months after
+   every version without it is obsolete and unsupported.
+
+4. Requiring features (for clients)
+
+   Clients take the longest time to update, and are often the least able
+   to fetch upgrades. Because of this, we should be very careful about
+   making subprotocol versions required on clients, and should only do
+   so for fairly compelling reasons.
+
+   We SHOULD NOT make a feature required for clients until it has been
+   _recommended_ for clients for at first 9 months.
+
+   We SHOULD make a feature required for clients if it has been
+   _recommended_ for clients for at least 18 months.
+
+