commit f31e0e0ba41ba2f26888c86ac264708988d185b6 Author: Nick Mathewson <nickm@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