Summary

  • At the RIPE 92 Community Plenary, Robert Kisteleki described domains for which he is an administrative or technical contact, including some owned by others. He named mail, VMs, secondary DNS, renewals and account recovery as services that can stall when one maintainer becomes unavailable.
  • He invited volunteers to develop possible RIPE guidance on personal continuity, including who can take over and how a former trusted helper loses access. The official talk record calls this a proposal for a document or Best Current Practice, not a completed standard.

The domain belongs to someone else. The renewal reminder goes to Robert Kisteleki. That small mismatch was the sharpest example in his RIPE 92 talk. Kisteleki said he is listed as an administrative and technical contact for several domains, including domains he does not own. If he cannot act, the people publishing under those names still need the names to resolve and the bills to be paid. Their dependency may exist only in his inbox and memory.

Speaking as a community member in Edinburgh on 21 May 2026, Kisteleki widened the list. A volunteer may run another person’s mail server or MX record, lend a VM, host hardware, provide secondary DNS or operate a small social-service instance. These favours are part of how network communities have helped one another for years. Each favour also has a maintenance clock. Domains expire, hosting bills come due, certificates need renewal, and a forgotten password or lost second-factor device demands a human who can restore access.

The plenary transcript sets out the operational trap in plain terms. A domain allowed to expire may be taken by someone else, who can then try recovery flows tied to addresses at that domain. A machine can vanish after non-payment. A security fix waits for a maintainer who is absent. These are Kisteleki’s failure scenarios, not a report that any named domain in his care suffered them. They show why an informal favour needs a formal answer to one practical question: who is allowed to act next?

The answer cannot be “give everyone a spare password.” Kisteleki raised the reverse problem as well: a person who once deserved access may no longer be trusted. Continuity needs a delegate, a way to establish when that delegate may step in, and a way to withdraw the delegate’s authority. A list of secrets passed around by email solves the first hour and creates the next incident. An inventory of services, owners, renewal obligations, recovery routes and revocation rights gives the successor a map without turning every friend into a permanent administrator.

At the meeting, Kisteleki proposed gathering people to produce a possible RIPE document or Best Current Practice. He had interested volunteers and expected to work out the venue and table of contents later. Jan Zorz suggested the Best Current Operational Practices Task Force as a home; the chair welcomed the thought. The official session abstract describes exactly that early stage: an idea for guidance about services community members provide in personal capacities. There was no finished document on the table.

The distinction between a service owner and a helpful operator matters. The owner must know which registrar account, DNS zone, payment method and recovery channel keeps the service running. The operator must know what authority they have and how another person can replace them. If those facts live in one person’s head, the community has built a hidden single point of failure while calling it generosity.

Kisteleki’s ask was modest: start a shared list of cases and practical steps. It was also a challenge to an old habit. A network can be distributed on paper and still hinge on one volunteer’s phone, card and calendar. The first useful continuity plan would make that dependency visible to the people who bear it, while the original maintainer is still there to explain it.