the rationale here is those were not explicitely rejected, but more
that they are out of scope or were found later.

If they are the same we may end up with more than one host derotated.

The problem is as follows:  as soon as shutdown runs, mininag derotated the
host.  So we start at time T, host a starts its shutdown, gets derotated, at
T+30 reboots and at T+40 mininag likes it again.  Host b starts its shutdown at
time T+30 and thus gets derotated.  So between T+30 and T+40, we will not like
a nor b.

Mostly to be granted only as last resort. Demand that problems be
documented in the service page.

Also includes some clarification in the wording.

Also moves the dgoulet example down because it's actually a
counter-example.

The minutes were read and agreed upon by TPA, so I assume this
reflects the current will of the team. This will help in case there
are bits of the policy that are unclear in the future.

This is based on the current "vetting" policy but also includes a
reference to the Tor Core Membership policy, to which we delegate the
revokation bit. We also assert that admins MUST be core tor to have
access.

This also introduces a link to the core membership policy which we
refer to elsewhere in the document.

This silences a warning when rebuilding the initrd.

In any case, unmounting this was giving me trouble this time.