Apply notes from last month's meeting about prop264,266.

2 files changed, 73 insertions, 9 deletions

diff --git a/proposals/264-subprotocol-versions.txt b/proposals/264-subprotocol-versions.txt
index 240422b..077ae55 100644
--- a/proposals/264-subprotocol-versions.txt
+++ b/proposals/264-subprotocol-versions.txt
@@ -116,18 +116,19 @@ Status: Open
 
 4. Required protocols
 
-   The consensus may contain three lines: RequiredRelayProtocols,
-   RecommendedClientProtocols, and RequiredClientProtocols.  Each has
-   the same format as the "protos" line.  To vote on these entries, a
-   protocol/version combination is included only if it is listed by a
-   majority of the voters.
+   The consensus may contain four lines: RecommendedRelayProtocols,
+   RequiredRelayProtocols, RecommendedClientProtocols, and
+   RequiredClientProtocols.  Each has the same format as the "protos" line.
+   To vote on these entries, a protocol/version combination is included only
+   if it is listed by a majority of the voters.
+
+
+   When a relay lacks a protocol listed in RecommendeddRelayProtocols, it
+   should warn its operator that the relay is obsolete.
 
    When a relay lacks a protocol listed in RequiredRelayProtocols, it
    must not attempt to join the network.
 
-   When a relay lacks a protocol listed in RecommendedRelayProtocols, it
-   should warn its operator that the relay is obsolete..
-
    When a client lacks a protocol listed in RecommendedClientProtocols,
    it should warn the user that the client is obsolete.
 
@@ -139,7 +140,14 @@ Status: Open
    protocol is required, and it does not implement that protocol, it
    SHOULD NOT try to fetch a newer consensus.
 
-   The above features should be backported to 0.2.4 and later.
+   The above features should be backported to 0.2.4 and later, or all the
+   versions we expect to continue supporting.
+
+
+   These lines should be voted on, and should require a supermajority of
+   authorities (2/3) to make a protocol required.  The required protocols
+   should not be torrc-configurable, but rather should be hardwired in the
+   Tor code.
 
 
 5. Current protocols
diff --git a/proposals/266-removing-current-obsolete-clients.txt b/proposals/266-removing-current-obsolete-clients.txt
index 7a490be..d803c41 100644
--- a/proposals/266-removing-current-obsolete-clients.txt
+++ b/proposals/266-removing-current-obsolete-clients.txt
@@ -203,3 +203,59 @@ Status: Draft
 
    [This proposal would result in the quietest shutdown.]
 
+A. How to "pull the switch."
+
+   This is an example timeline of how we could implement 3.3 above,
+   along with proposal 264.
+
+     TIME 0:
+        Implement the client/relay side of proposal 264, backported
+        to every currently existant Tor version that we still
+        support.
+
+        At the same time, add support for the new consensus type to
+        all the same Tor versions.
+
+        Don't disable anything yet.
+
+     TIME 1....N:
+        Encourage all distributions shipping packages for those old
+        tor versions to upgrade to ones released at Time 0 or later.
+
+        Keep informed of the upgrade status of the clients and
+        relays on the Tor network.
+
+
+     LATER:
+        At some point after nearly all clients and relays hav
+        upgraded to the versions released at Time 0 or later, we
+        could make the switchover to publishing the new consensus
+        type.
+
+
+B. Next steps.
+
+   We should verify what happens when currently extant client
+   versions get an empty consensus.  This will determine whether
+   3.3 will not work.  Will they try to fetch a new one from the
+   authorities at the end of the validity period.
+
+   Another option is from Roger: we could add a flag meaning "ignore
+   this consensus; it is a poison consensus to kill old Tor
+   versions."  And maybe we could have it signed only by keys that
+   the current clients won't accept.  And we could serve it to old
+   clients rather than serving them the real consensus.  And we
+   could give it a really high expiration time.  New clients
+   wouldn't believe it.  We'd need to flesh this out.
+
+   Another option is also from Roger:  Tell new clients about new
+   locations to fetch directories from.  Keep the old locations working
+   for as long as we want to support them.  We'd need to flesh this
+   out too.
+
+   The timeline above requires us to keep informed of the status of
+   the different clients and relays attempting to connect to the tor
+   network.  We should make sure we'll actually able to do so.
+
+   http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-02-12-15.01.log.html
+   has a more full discussion of the above ideas.