wiki:org/meetings/2016WinterDevMeeting/Notes/DirectoryAuthorityOperators

We discussed how directory authorities make decisions. The history of how decisions have been made in the past about who the directory authorities would be were made together, the idea being that those people who did the work, made those decisions, and kept it as that set. Everyone sets the intention to try and do the right thing.

Micah raised Sebastian's point about striving for consensus, but give a severity-influenced timeout was raised, people generally thought this was a reasonable approach, but there were murmurs of dissention at the idea of creating categories for timeouts.

We also discussed a bit about why the number 9, and we don't have to just stick with that number, but what increasing that number would mean. It was floated that maybe 9 isn't an upper limit. If the problem is human beings responding is important, and if we are 26 and more people than before are not responding then a lower number makes sense, but, but if 26 people are really good at responding would be ok and be more diverse.

There were four people who had expressed interest in helping as directory authorities at the meeting (stefani, helix, george, nick calyx), and it was pointed out that we don't need to make this something where we pick one of them, and the rest lose, we can add more than one, or we can have them do other things like bwauth, or we can create a merit queue where choice people are put in a queue based on when they first expressed interest, and then they were picked from that queue when the need arises.

in the past: when we raised numbers, we did it in pairs (eg. 7 to 9).

We discussed who would be the ones to decide about kicking out directory authorities. Do the dirauths themselves decide this, or the project? What is the escalation process, if anything? Maybe there should be a mechanism in place to file concerns?

Both Mozilla and ACLU offered their organizational resources (technical, labor, organizational, legal, etc.) and would be happy to run a directory authority. We discussed how historically, we have picked a person that we trust, not an organization, and its a better person if they have an organization behind them, but it shouldn't be an organization. If Mozilla wants to do this, then mozilla should find their best person and puts them forward as the person who would run the authority and then this would be evaluated.

Roger said that if we need directory auths responding quickly to act on something is actually bug in the protocol. People shouldn't have to read their email every minute to do it right, and it is not a good situation that we have this problem.

We then went over the rough list of 'fitness criteria' that were developed in Valencia and wrote them down on individual post-it notes, and asked people to come up with additional ones that were missing.

Someone raised port diversity as something that was missing, but after discussing what fall-back criteria are, it seemed as if port diversity doesn't matter so much now because of that.

We then distributed little dots to each person so that they could come up to the sticky notes and place their dots on them for the things that they thought were more important than others. Current directory authorities were given different colors, so that we could differentiate between what dirauths thought, compared to whoever was at this particular meeting. Isis, as new bridge auth was included in this dot color. Micah took a set of dots to try and represent Sebastian's stated preferences on the list. He only deployed two of those.

It was noted that in previous dot exercises people had a negative dot color, but this was too complicated for us to do on the spot.

Of the different criteria that were on post-it notes, these are the ones that received votes, the first number is the number of non-dirauth votes, the second is the number of votes from dirauths. There were some that did not receive votes, which is normal because people only had four dots.

good communications: 8 other, and 6 dirauth (including 1 from sebastian via micah)

operator response time: 10 other, 5 dirauth (including 1 from sebastian via micah)

history of running high-availability high risk services: 7 other, 5 dirauth

gender diversity: 4 other, 2 dirauth

controlling bare metal: 5 other, 4 dirauth

robustness/link quality: 6 other, 3 dirauth

os diversity: 5 other

political diversity: 4 other, 1 dirauth

isolated services: 3 other, 2 dirauth

We had a go-around discussion about what we could learn/observe from the results of the votes, but this was too difficult to take notes about.

In the end, we came up with the following "next steps":

  1. encourage interested people to run dirauths in the test network, and existing dirauths should also join that test network so they can evaluate how interested people operate with their test net dirauth
  1. encourage interested people to run high capacity relays in the real tor network
    1. encourage existing people to run bwauths now, and pair with existing directory authorities who trust them to serve that data.
  1. the current directory auths need to go back to the cave and build a process
  1. tell the world that we want new dirauths, this is what we want, if you are interested, tell us
  1. aclu/mozilla go back and talk to people in their organization to try and find things that work.
Last modified 20 months ago Last modified on Mar 25, 2017, 9:00:58 AM