[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
higher.
@@ -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