[tor-commits] [torspec/master] Merge 235-kill-named-flag.txt into dir-spec.txt

nickm at torproject.org nickm at torproject.org
Wed Mar 8 16:48:41 UTC 2017

commit f31e0e0ba41ba2f26888c86ac264708988d185b6
Author: Nick Mathewson <nickm at torproject.org>
Date:   Wed Mar 8 11:42:37 2017 -0500

    Merge 235-kill-named-flag.txt into dir-spec.txt
 dir-spec.txt                      | 64 ++++++---------------------------------
 proposals/235-kill-named-flag.txt |  2 +-
 2 files changed, 11 insertions(+), 55 deletions(-)

diff --git a/dir-spec.txt b/dir-spec.txt
index 69697b5..f72659d 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -2055,14 +2055,10 @@
           "Fast" if the router is suitable for high-bandwidth circuits.
           "Guard" if the router is suitable for use as an entry guard.
           "HSDir" if the router is considered a v2 hidden service directory.
-          "Named" if the router's identity-nickname mapping is canonical,
-             and this authority binds names.
           "NoEdConsensus" if any Ed25519 key in the router's descriptor or
              microdesriptor does not reflect authority consensus.
           "Stable" if the router is suitable for long-lived circuits.
           "Running" if the router is currently usable.
-          "Unnamed" if another router has bound the name used by this
-             router, and this authority binds names.
           "Valid" if the router has been 'validated'.
           "V2Dir" if the router implements the v2 directory protocol or
@@ -2257,31 +2253,10 @@
    known to be broken, and the directory authority has not blacklisted
    it as suspicious.
-   "Named" -- Directory authority administrators may decide to support name
-   binding.  If they do, then they must maintain a file of
-   nickname-to-identity-key mappings, and try to keep this file consistent
-   with other directory authorities.  If they don't, they act as clients, and
-   report bindings made by other directory authorities (name X is bound to
-   identity Y if at least one binding directory lists it, and no directory
-   binds X to some other Y'.)  A router is called 'Named' if the router
-   believes the given name should be bound to the given key.
-        Two strategies exist on the current network for deciding on
-        values for the Named flag.  In the original version, relay
-        operators were asked to send nickname-identity pairs to a
-        mailing list of Naming directory authorities' operators.  The
-        operators were then supposed to add the pairs to their
-        mapping files; in practice, they didn't get to this often.
-        Newer Naming authorities run a script that registers routers
-        in their mapping files once the routers have been online at
-        least two weeks, no other router has that nickname, and no
-        other router has wanted the nickname for a month.  If a router
-        has not been online for six months, the router is removed.
-   "Unnamed" -- Directory authorities that support naming should vote for a
-   router to be 'Unnamed' if its given nickname is mapped to a different
-   identity.
+   "Named" --
+   "Unnamed" -- Directory authorities no longer assign these flags.
+      They were once used to determine whether a relay's nickname was
+      canonically linked to its public key.
    "Running" -- A router is 'Running' if the authority managed to connect to
    it successfully within the last 45 minutes.
@@ -2498,6 +2473,7 @@
           the more recently published, then in favor of smaller server
           descriptor digest.
+       [
         * The Named flag appears if it is included for this routerstatus by
           _any_ authority, and if all authorities that list it list the same
           nickname. However, if consensus-method 2 or later is in use, and
@@ -2511,6 +2487,10 @@
           (With consensus-method 1, Unnamed is set like any other flag.)
+          [But note that authorities no longer vote for the Named flag,
+          and the above two bulletpoints are now irrelevant.]
+       ]
         * The version is given as whichever version is listed by the most
           voters, with ties decided in favor of more recent versions.
@@ -3364,31 +3344,7 @@ The following methods have incorrect implementations; authorities SHOULD
 5.4.2. Managing naming
-   In order to provide human-memorable names for individual router
-   identities, some directory servers bind names to IDs.  Clients handle
-   names in two ways:
-   When a client encounters a name it has not mapped before:
-      If the consensus lists any router with that name as "Named", or if
-      consensus-method 2 or later is in use and the consensus lists any
-      router with that name as having the "Unnamed" flag, then the name is
-      bound.  (It's bound to the ID listed in the entry with the Named,
-      or to an unknown ID if no name is found.)
-   When the user refers to a bound name, the implementation SHOULD provide
-   only the router with ID bound to that name, and no other router, even
-   if the router with the right ID can't be found.
-   When a user tries to refer to a non-bound name, the implementation SHOULD
-   warn the user. After warning the user, the implementation MAY use any
-   router that advertises the name.
-   Not every router needs a nickname.  When a router doesn't configure a
-   nickname, it publishes with the default nickname "Unnamed".  Authorities
-   SHOULD NOT ever mark a router with this nickname as Named; client software
-   SHOULD NOT ever use a router in response to a user request for a router
-   called "Unnamed".
+   (This section is removed; authorities no longer assign the 'Named' flag.)
 5.4.3. Software versions
diff --git a/proposals/235-kill-named-flag.txt b/proposals/235-kill-named-flag.txt
index 3d03a91..238315a 100644
--- a/proposals/235-kill-named-flag.txt
+++ b/proposals/235-kill-named-flag.txt
@@ -3,7 +3,7 @@ Title: Stop assigning (and eventually supporting) the Named flag
 Authors: Sebastian Hahn
 Created: 10 April 2014
 Implemented-In: 0.2.6, 0.2.7
-Status: Finished
+Status: Closed
 1. Intro and motivation

More information about the tor-commits mailing list