Relay-EOL-policy.md

@@ -7,20 +7,20 @@ users at risk due to unpatched security vulnerabilities in unmaintained Tor code
 The following document outlines steps we intend to take in order to deal with
 this problem.
 
-If no one else has done it we inform the tor-relays mailing list that a Tor
-series is about to become EOL (maybe 2 to 3 weeks before that actually happens).
+1) If no one else has done it yet, then we inform the tor-relays mailing list
+   that a Tor series is about to become EOL (maybe 2 to 3 weeks before that
+   actually happens).
 
-Once a Tor series becomes EOL we make sure its respective versions are not
+2) Once a Tor series becomes EOL we make sure its respective versions are not
    recommendend anymore.
 
-Later on, after n[2] weeks, we start with the following process:
+Later on, after n[2] weeks, we start with the following steps:
 
-1) Figure out which relays and bridges are running a Tor version that is EOL.[3]
-2) File a ticket at core/tor to reject the EOL versions at the directory
+3) Figure out which relays and bridges are running a Tor version that is EOL.[3]
+4) File a ticket at core/tor to reject the EOL versions at the directory
    authority level
-3) Double-check that the EOL series is not recommended anymore at the dir-auth
    level and fix that if needed.
-4) Contact those operators that have a valid contact information asking them to
+5) Contact those operators that have a valid contact information asking them to
    upgrade to a supported Tor version.
    * This happens over email in a first round keeping the eol-relays@ alias in
      Cc.
@@ -28,16 +28,16 @@ Later on, after n[2] weeks, we start with the following process:
      media with a general reminder to upgrade EOL relays/bridges.
    * Update the list each week during the notification cycle and reach out to
      operators not contacted previously.
-5) After waiting about 4 weeks we generate a list of relays and bridges still
+6) After waiting about 4 weeks we generate a list of relays and bridges still
    not having upgraded.
-6) We reject the group found in 5. from the network, potentially making an
+7) We reject the group found in 5. from the network, potentially making an
    announcement to the tor-relays mailing list to inform operators about what is
    going on or maybe writing a blog post
    [as we did in the past](https://blog.torproject.org/removing-end-life-relays-network).
    Instead of rejecting the whole set at once we might start with a smaller
    amount of relays/bridges, taking other factors like network stability and
    censorship circumvention needs into account.
-7) If possible (because the directory authorities are running a respective Tor
+8) If possible (because the directory authorities are running a respective Tor
    version now) and needed we clean up our reject file, removing previously
    blocked fingerprints as the EOL Tor versions are now blocked at the directory
    authority level.