Summary

  • No clock hour is uniformly quiet for global number-resource users. A window chosen around the registry's office hours can coincide with a carrier change, a security response, a transfer closing, a public holiday ending, or a government service peak elsewhere.
  • Fairness begins with service dependency rather than equal inconvenience. The registry should distinguish public lookup, authenticated account access, write transactions, RPKI publication, reverse DNS, routing registry data, billing and support, then identify which users cannot safely defer each function.
  • Planned work should not proceed merely because a redundant component exists on a diagram. The fallback path must be current, independently monitored, sufficiently isolated from the change, and tested under the same failure assumptions that make the maintenance risky.
  • Regional rotation is necessary for recurring discretionary work, but rotation is not enough. A dependency-weighted exception can be justified for a genuinely critical period only if the reasons, evidence, compensating controls and displaced burden are recorded.
  • Notices should state exact affected operations, stale-data behavior, rejected or queued writes, expected recovery, abort criteria, escalation channels and time-zone translations. Saying that a service is "available" while it serves frozen data is materially incomplete.
  • Actual impact should be measured from both independent probes and user outcomes. Duration alone misses failed transactions, stale responses, delayed publication, repeated retries, geographic concentration and the time needed to clear a post-maintenance backlog.
  • Affected operators need enforceable procedural rights: timely notice, an emergency route, transaction receipts, preservation of failed requests, correction of misleading status reports, and review when a repeated schedule imposes a concentrated regional burden.
  • Number Resource Society can compare notice quality, propose a rotation ledger and help smaller operators document dependency. It should not choose maintenance hours for registries, certify resilience it cannot inspect, or promise compensation beyond the governing contracts.

The quiet hour that does not exist

Imagine a network group with operating teams in Auckland, Singapore, Nairobi, London, Sao Paulo and Los Angeles. Its central registry account is administered from one location, security monitoring from another, and routing changes from a third. A planned registry window begins at midnight in the registry's home city. For the registry staff, that is a conventional low-traffic period with senior engineers available nearby. For one customer team it is the start of a business day. For another it is the final hour of a transfer closing.

Elsewhere, a carrier is responding to a cable fault and needs to change a route authorization before moving traffic.

The title's twelve time zones are not a statistical claim about every operator. They describe the ordinary governance problem created when an authoritative regional service is used by networks whose business, customers and incident clocks are global. Internet number resources are regionally administered but globally routed. A maintenance decision made in one city can therefore distribute risk to organisations that neither share its night nor enjoy its fallback arrangements.

The easy answer is to publish the time in Coordinated Universal Time. UTC removes ambiguity, which is valuable, but it does not remove burden. A precise timestamp tells an operator when the inconvenience will occur; it does not explain why that operator should repeatedly carry it. Nor does a weekend solve the problem. Weekends differ across jurisdictions, consumer traffic may rise, and reduced staffing can make a nominally quiet period harder to recover from.

A registry cannot find a moment at which nobody depends on it. The defensible objective is narrower: reduce avoidable risk, assign the remaining risk according to disclosed operational reasons, prevent the same communities from absorbing every discretionary window, and measure the consequence after the change. That turns maintenance from a calendar habit into an accountable allocation decision.

Planned does not mean harmless

Planned maintenance is often discussed as the opposite of an incident. Operationally, the categories overlap. A maintenance event intentionally reduces redundancy, pauses writes, withdraws an interface or changes a dependency. An incident does much the same without advance consent. The relevant distinction is that planned work offers time to understand and control the exposure.

That opportunity creates a higher, not lower, duty to be specific. If an unplanned fault interrupts a service, uncertainty may be unavoidable. Before planned work, the operator can identify which components will change, which services will degrade, how users will observe the degradation, how long rollback takes, and which conditions require an abort. A notice that merely says "systems maintenance" leaves unused information in the hands of the party best able to provide it.

The word "downtime" can itself be misleading. A public RDAP endpoint may continue answering while its underlying registration state is frozen. An RPKI repository may remain downloadable while new entities cannot be published. A portal may display resources while rejecting changes. An Internet Routing Registry may serve old route objects while updates wait. From an infrastructure monitor, these services are up. From the user trying to complete a time-sensitive act, they are unavailable.

Conversely, the loss of one interface need not create equal harm if an equivalent route remains. A web search failure may be tolerable where direct RDAP works and the notice explains it. An account portal outage may matter less if urgent security changes can be accepted through an authenticated emergency channel. The impact is determined by the capability left to the user, not the colour of one component on a status page.

Treating planned work as controlled risk also changes the burden of proof. The registry need not guarantee that no user will be affected; such a guarantee would be implausible. It should be able to show that it knew which capabilities were exposed, tested the safeguards, considered regional concentration, and reported deviations from the plan.

Since 2010, the dependency surface has widened

The maintenance question became more consequential during the period covered here because registry service ceased to mean only a public Whois query and a member account. Operators now use structured RDAP responses, automated provisioning, hosted routing-security functions, repository publication, richer routing registries, federated identity and service-status interfaces. The services did not all appear at once or develop identically in every region. Their cumulative effect is to place more time-sensitive acts behind interconnected registry systems.

RDAP was standardized in 2015, making automated registration lookup more consistent while increasing the importance of stable HTTP service behaviour. RPKI adoption gave a resource holder a cryptographically verifiable way to state route-origin authorization, but hosted administration and publication also created operational dependencies distinct from ordinary directory lookup. RRDP, standardized in 2017, improved repository distribution while making notification, snapshot and delta freshness meaningful to relying parties. Member portals accumulated identity, transfer, payment and delegated-user functions.

The result is not simply that registries became more important. It is that "the registry is down" became less informative. One maintenance event may affect only a user interface. Another may preserve public reads but prevent new publication. A third may leave authoritative functions intact while an analytics service pauses. The fairness analysis has to follow these branches.

Automation also changed the shape of recovery. A human user may wait and retry once. Hundreds of clients may reconnect together, creating a surge after a planned pause. A write queue can preserve intent but introduce ordering and duplication questions. A read cache can protect continuity but conceal staleness. Since 2010, resilience has increasingly depended on state and recovery semantics, not merely a second server.

This historical widening supports a stricter notice discipline without implying that every modern service is critical. The registry should identify the capabilities that acquired operational consequence, fund resilience according to that consequence, and retire outdated assumptions that one quiet local hour describes the whole service.

Start with capabilities, not product names

Maintenance planning often begins with a list of applications: portal, database, certificate service, billing system. Operators experience capabilities instead. The first governance improvement is to translate the application list into acts that users may or may not perform.

For registration data, separate read from write. Can a user look up the current holder of an address range? Can a resource holder change an organisation or contact record? Will an accepted change become visible through RDAP and Whois during the window? Can an operator create or modify an Internet Routing Registry entity? If a write is unavailable, will it be rejected, held safely, or accepted without a completion guarantee?

For routing security, distinguish repository retrieval, certificate authority management and publication. A validator's ability to fetch existing material is different from a holder's ability to issue or revoke a Route Origin Authorization. A cached entity may carry the network through a short interruption, but that does not help an operator that must authorize an emergency origin. Manifest and certificate validity periods add another clock that a maintenance plan must respect.

For reverse DNS, separate continued serving of the delegated zone from the ability to change delegation or DNSSEC material. For member administration, distinguish viewing resources, updating users, filing a transfer, paying an invoice and reaching support. Public-sector continuity may depend on one narrow function even when most of the service catalogue can wait.

This capability map should identify authoritative and advisory functions. A delayed statistics page is not the same as a delayed authorization change. A training portal is not the same as a reverse-DNS delegation. Ranking them is not an insult to the lower tier; it ensures that scarce resilience is placed where delay can change network behaviour, legal position or public access.

Once these distinctions are public, maintenance notices become intelligible. Operators can decide whether to defer their own work, activate a local safeguard or request an exception. The registry can measure the outcome at the level users actually encountered.

Dependency is the proper unit of fairness

Equal treatment is not achieved by imposing the same nominal outage on everyone. A large multinational may have several credentialed administrators, cached registration data, alternative routes and a staffed operations centre. A small operator may have one administrator, one upstream and no safe way to postpone a customer migration. A public safety network may have high consequence but infrequent registry interaction. A broker may be able to delay a transfer but face a contractual closing date. The same two-hour window is not the same risk.

Dependency analysis asks four questions. First, how quickly does the user need the capability under ordinary conditions? Second, what event could make it urgent during the window? Third, what substitute exists and who can operate it? Fourth, what harm persists after the service returns? The last question captures queues, expired deadlines and changes that must be re-entered.

The registry will not know every customer's architecture. It can still identify classes of dependency through member consultation, service telemetry, support cases and prior maintenance. It can ask operators to register critical-use statements without requiring disclosure of sensitive network detail. It can invite National Internet Registries and sector groups to describe regional peaks and local constraints.

Dependency must not become a route for the loudest or richest member to reserve every favourable hour. Claims should be specific, time-bounded and reviewed. A global cloud company should not receive preference merely because it is large. A small emergency communications provider should not have to demonstrate an impossible worldwide denominator before its consequence is taken seriously.

The output is a dependency register, not a ranking of members' worth. It describes capabilities, scenarios, fallback and evidence. Scheduling then minimizes high-consequence simultaneous exposure while rotating ordinary inconvenience. This is more defensible than a poll in which each respondent votes for its own night.

Redundancy must survive the change being made

Maintenance proposals often include the reassuring line that redundant services will remain available. The claim is only as strong as the independence of the fallback. Two instances can share a database, identity provider, network edge, cloud control account, certificate, software release or administrator error. A change aimed at that shared dependency can remove both.

Before the window, engineers should state the failure assumption. If the new database release corrupts writes, can the old state be restored without replaying corrupt transactions? If the identity provider fails, can emergency administrators authenticate through a separately controlled route? If a cloud edge rejects requests, can users reach an origin safely? If DNS changes propagate badly, is the previous delegation still valid and available?

A successful test last quarter is not conclusive. Configuration, data volume, credentials and external dependencies change. The fallback should be tested close enough to the event to reflect current conditions, but not in a way that creates another unannounced risk. Read-only replicas should be checked for freshness. Backup restoration should be timed. Emergency contacts should acknowledge the test. Independent probes should verify the user-facing path from more than the registry's own network.

Capacity matters as much as technical reachability. A fallback that handles a small test request may collapse under the retry storm created by a primary outage. Clients often retry together. Human users refresh portals. Automated tools reconnect. Rate controls may protect the service while preventing urgent users from completing work. The test should include realistic failure traffic and a plan to shed low-priority load without making the emergency route a private privilege.

The governing body does not need every configuration detail. It does need assurance tied to the actual change: what was tested, by whom, under which failure assumption, with what unresolved weakness. Generic declarations of high availability are not enough.

Rotation is governance, not theatre

For recurring maintenance that cannot be made invisible, regional rotation is the simplest protection against habitual burden. If a monthly task always occurs at 02:00 in the registry's home time, the same overseas communities may repeatedly receive business-hour risk. A rotation ledger makes that pattern visible and changes the default.

The ledger should record the affected capabilities, local times across significant user regions, dependency exceptions, expected burden and actual outcome. Over a defined period, discretionary windows should move among regional bands. The goal is not mathematical equality to the minute. Seasonal clock changes, engineering staffing, vendor access and regional holidays make that impossible. The goal is to prevent convenience at headquarters from becoming an unwritten entitlement.

Rotation also disciplines claims that one hour is always least busy. Aggregate request volume can be dominated by automated lookup traffic and may not represent the importance of a write. A low-volume period may still contain a financial closing or a regular national maintenance night. Publishing the method used to choose a window allows affected groups to challenge a false proxy.

Exceptions will be necessary. A major data-centre provider may permit work only at a fixed time. A certificate or software deadline may constrain the date. A regional emergency may make an otherwise scheduled rotation reckless. An exception is legitimate when the registry records the constraint, considers alternatives, adds protection, and later restores balance. It is suspect when "staff availability" appears every time without investment in distributed on-call capability.

Rotation cannot compensate for weak redundancy. Moving a dangerous outage from Asia to Africa to the Americas is not resilience. It is fairer only after avoidable failure has been removed. The sequence is dependency, reduction, protection, rotation, measurement.

Notice is an operating control

A maintenance notice is often treated as courtesy text. It should be designed as part of the control system. An operator uses it to freeze local changes, extend staffing, preserve current data, warn customers or move a transaction. Ambiguity consumes the very preparation time that advance notice is meant to create.

At minimum, the notice should give start and end in UTC, translated local times for the principal regional bands, the change purpose, affected capabilities, unaffected alternatives, data-freshness behaviour, transaction handling, expected recovery and a stable status location. It should say whether writes will be rejected, queued or accepted for later processing. Those states carry different risks: rejection is visible, a durable queue needs a receipt, and silent acceptance without timely effect is the most dangerous.

The notice should identify abort criteria without exposing attackable detail. Examples include loss of the independent read path, replication lag beyond a threshold, failed integrity checks, unexpected authentication errors or inability to restore within the reserved rollback period. Users then know that the announced end is an estimate governed by safety, not a promise that will force engineers to continue a bad change.

Notice periods should reflect consequence and reversibility rather than one blanket number. Routine work with tested failover may require less lead time than a long portal and write freeze. A shortened notice should state why delay would create greater risk. Material changes should be announced through more than one channel, because an email list and a status page can fail in different ways.

RIPE NCC's 2022 announcement that its status dashboard was hosted outside its own infrastructure illustrates a useful principle: the communication path should survive a major failure of the service it describes. The same principle applies to contact lists, emergency numbers and archived notices.

The difference between stale and unavailable

An ARIN maintenance notice for 28 March 2026 provides a concrete example of capability-specific language. It said ARIN Online would be inaccessible, certain RESTful and RPKI transactions would be rejected rather than queued, and public Whois, RDAP, IRR and RPKI repository services would remain operational without publishing updates during the window. Whatever one thinks of the twelve-hour interval chosen, the notice gives operators information that the word "downtime" would conceal.

A user reading existing data could continue. A user submitting a listed transaction had to wait and resubmit. A user relying on current publication had to understand that an apparently healthy response could be frozen. These are three different service states and three different operational decisions.

This distinction should become standard. Status systems often offer only operational, degraded and outage labels. Registry services need a freshness dimension: current, delayed within a declared bound, frozen as of a stated time, or uncertain. A timestamp should identify the authoritative state represented, not merely the time the web server answered.

For writes, the service should issue a machine-readable result. A rejected request should explain that no action was taken and whether the client should retry. A queued request should provide a durable identifier, ordering rule and cancellation route. An accepted but not yet published request should state the expected publication state and allow the user to check it without submitting duplicates.

After restoration, the registry should confirm that the queue is clear and replicas are current. "Maintenance completed" is not a sufficient statement if updates remain delayed. The recovery period ends when promised capabilities and freshness are restored, not when engineers close the change ticket.

Availability percentages need a denominator users can understand

A quarterly availability number can support accountability, but only if the measurement method is disclosed. Does the denominator include planned maintenance? Are read and write paths combined? Does one failed probe count the same as every user receiving errors? Are stale successes treated as available? Are regional failures averaged away?

APNIC's report on registry service availability during the fourth quarter of 2025 describes a combined method using external probes and user-perspective error rates. It also explains how overlapping observations were handled to avoid counting one outage twice. That methodological discussion is at least as valuable as the headline percentages because it tells readers what the number means and what it cannot mean.

APNIC's earlier 2023 consultation on critical-service availability reported different perceived consequences for reverse DNS, route-authorisation publication and other states, and it recorded disagreement about paying for higher targets. The sample was bounded and should not be treated as a vote by the entire region. Its larger lesson is that availability has cost, that impact differs by capability, and that accuracy can matter more than uninterrupted delivery of a wrong state.

A fair maintenance report should therefore publish several denominators. Time availability captures duration. Request success captures user outcomes. Transaction completion captures writes. Freshness captures how long authoritative data lagged. Geographic distribution captures concentrated failure. Backlog clearance captures the tail after the public endpoint returns.

No single global denominator can reveal every affected operator. The registry should disclose coverage gaps: where probes exist, which interfaces are measured, which clients supply outcome data and how privacy is protected. Honest incompleteness is more legitimate than a precise percentage whose excluded users carry the risk.

Measure actual impact, not just elapsed minutes

The post-maintenance record should begin with the plan: expected duration, affected capabilities, fallback, user regions and abort points. It should then report variance. Did the work start late? Did a supposedly unaffected service degrade? Were writes rejected as announced? Did data remain stale beyond the window? Did operators use the emergency route? How long did backlog clearance take?

Independent probes provide one view. They should query meaningful entities from several networks and verify response content, not only establish a TCP connection. A 200 response with old data may be technically successful and operationally misleading. For authenticated services, privacy-preserving synthetic transactions can test that the act works without exposing member records.

User outcomes provide another view. Count failed requests, repeated retries, abandoned sessions, rejected writes and support contacts by broad region and capability. Avoid publishing small cells that identify individual users. A sharp regional concentration can appear even when the global error rate is modest. That concentration is central to the fairness question.

Consequential cases require qualitative review. One delayed route authorization during an emergency may matter more than thousands of harmless lookup retries. The report should not name the operator without permission, but it can classify the event, explain the control that failed and describe the remedy. Severity and count are complementary.

Finally, the registry should compare prediction with reality. If a fallback expected to carry full load reached only half of it, the next change must use the observed capacity. If users misunderstood stale-data language, the notice format must change. Maintenance evidence has governance value only when it alters the next decision.

Time zones are not the only geography

Clock rotation can conceal other regional disadvantages. International links may be more fragile in one area. A region may rely on a distant cloud edge or a narrow set of transit providers. Local operators may share carrier-grade NAT, causing a defensive control to aggregate them. Language and holiday calendars affect whether notice reaches the right people. Sanctions or payment restrictions may slow access to vendor support.

Monitoring is geographically uneven too. A registry may have many probes in Western Europe and North America and few in island economies or parts of Africa. The global status can look healthy because the best-observed paths remain healthy. A maintenance review should publish broad probe distribution and recruit observation points where dependency is high and visibility weak.

National Internet Registries add another layer in parts of the Asia-Pacific region. Members may interact through a national body while relying on APNIC-operated critical services underneath. Notice and escalation must travel through both relationships without assuming that one intermediary represents every operator's consequence.

Public-sector networks can be hidden behind commercial providers. A hospital, emergency service or municipal system may not hold resources directly, yet its provider may need a registry act during a route leak or attack. Criticality declarations should allow this indirect dependency to be described without creating a privileged class of vaguely labelled "government" requests.

Fairness therefore requires a regional evidence programme, not only a rotating clock. The registry should seek input from under-observed communities, translate notices where appropriate, test access from their networks, and record when a nominal alternative is not practically reachable. Geographic equality on a spreadsheet is weak protection if the resilient route exists mainly for the best-connected users.

Change freezes should protect the public, not the calendar

Operators use change freezes around elections, major public events, year-end commerce, disaster seasons and large migrations. A registry needs its own calendar of ecosystem-sensitive periods, informed by members rather than copied from headquarters. The calendar should guide discretion, not create an absolute ban that prevents urgent security fixes.

The key distinction is necessity. A vulnerability patch with credible exploitation risk may justify work during a normally protected period. A cosmetic portal release does not. A certificate expiry created by poor internal planning should not automatically transfer risk to users, though refusing the immediate change may be worse. The review should record both the immediate necessity and the planning failure.

Change bundling deserves suspicion. Combining several upgrades can reduce the number of windows but enlarge the blast radius and complicate rollback. Splitting every change can create constant exposure. The defensible choice depends on shared dependencies, reversibility and test coverage. The notice should not hide a bundle behind one generic label.

A freeze exception should name an accountable decision-maker and the evidence considered. It should add compensating controls: more staff, a narrower scope, a tested fallback, extended observation, direct outreach to dependent operators or a staged regional release. If those controls cannot be arranged, postponement may be the rational decision.

The calendar must be reviewed after use. If every urgent exception falls in the same region's business hours, the organisation has an investment problem, not bad luck. Distributed engineering and vendor contracts cost money; repeatedly externalising the cost to distant operators is also a financial choice.

Abort and rollback are rights in practical form

An operator affected by maintenance cannot usually command the registry to stop. It can reasonably expect the registry to define conditions under which safety overrides completion. Abort criteria convert the abstract promise of care into a decision rule.

Criteria should cover more than total outage. Unexpected data changes, authentication failures, replication divergence, broken audit recording, loss of emergency communication or regional error concentration can justify an abort. Thresholds may remain partly confidential for security, but their categories and governance should be public.

Rollback must be a tested transaction, not a hopeful restoration of software. The registry should know how data written before and during the window will be reconciled, how duplicate requests will be prevented, how credentials and keys will return to a safe state, and how public caches will be corrected. Where rollback would itself be more dangerous than completing the change, the decision record should say so in advance.

Users need receipts because rollback can create ambiguity. A transaction identifier should let a holder prove whether a request was rejected, queued, committed, reversed or awaiting review. After a failed maintenance event, the registry should contact users whose actions are uncertain rather than requiring them to discover the problem later.

These controls also protect engineers. A published decision structure reduces pressure to continue because the scheduled end is approaching or senior managers want a declared success. Governance is useful when it permits a safe failure. A completed rollback with candid reporting may demonstrate more legitimacy than a nominally completed upgrade followed by quiet repair.

Vendor windows do not end registry responsibility

Modern registry services depend on cloud providers, content delivery networks, identity services, certificate authorities, data centres and telecommunications carriers. A vendor may set the available maintenance hour. That constraint is real, but it does not transfer accountability from the registry to a contract clause.

Procurement should require notice, regional options, emergency contacts, measurable recovery, access to incident evidence and coordination for high-risk changes. A vendor offering only one global hour effectively chooses which registry users carry the burden. The price of a better option should be compared with the expected public consequence, not only the IT budget.

Shared vendors create correlated risk across RIRs and operators. Two services described as independent may rely on the same identity provider or cloud edge. Cross-RIR continuity planning should map these concentrations without publishing exploitable detail. Planned work at one vendor should not coincide with discretionary work that removes another route.

Outsourcing communication can also fail. A status page hosted externally is valuable, but the registry needs a way to post if the status provider or identity account is unavailable. Contact ownership, domain control and archive access should not rest with one contractor.

The public report should identify the class of external dependency when relevant and distinguish what the registry knew from what it learned later. "Vendor issue" is not a root cause. The governance questions are why the dependency was accepted, which safeguards were contracted, whether they worked, and what will change.

Maintenance can collide with a real incident

The most demanding scenario is an unrelated network emergency during planned registry degradation. A route leak, distributed attack, credential compromise or natural disaster may require the very function that has been paused. Historical traffic averages cannot rule out this collision.

Every material window should therefore preserve an emergency path for a narrow set of acts. The path might accept a time-critical revocation, route authorization, reverse-DNS correction or account lock. It must authenticate the requester strongly and record the decision. It should not become a private general-purpose bypass for well-connected members.

Eligibility should be defined by consequence and act, with a published request route and after-the-fact review. A user denied emergency treatment should receive a reason and a way to challenge the classification. Abuse of the route can lead to restrictions, but restrictions should not erase access for a later genuine emergency without review.

The maintenance team also needs authority to pause its work when an external event changes the risk. That requires monitoring outside the registry: major routing anomalies, regional disasters and incidents reported by trusted operators. It does not require the registry to become a global security centre. It requires someone to ask whether the assumptions underlying the window are still true.

If the emergency path is used, the post-event account should say how many requests were received by broad class, how quickly they were handled and whether any were wrongly delayed. Sensitive operational details can remain protected. The existence and performance of the safeguard should not.

Enforceable procedure matters more than goodwill

Most users cannot recover the full economic harm of a registry interruption, and many service terms limit liability. A fair maintenance regime should not depend solely on damages. Procedural rights are more practical and can prevent recurrence.

Members should receive notice through registered channels, access to a durable status record, clear transaction outcomes and an emergency contact. They should be able to report a dependency conflict before the window and receive a reasoned response. Afterward, they should be able to correct a materially inaccurate impact account and request preservation of relevant records.

Repeated concentrated burden should trigger review. An operator need not prove intentional discrimination. It should show a pattern: similar work repeatedly placed in its critical hours, predictable consequence, and available alternatives not considered. The remedy may be future rotation, stronger fallback, direct notice or a revised vendor arrangement rather than money.

An independent complaint route matters when registry management is reviewing its own convenience. The NRO RIR Governance Document Version 2 sets broad expectations of stable, reliable, secure, accurate and accountable services, continuity and redundancy procedures, and fair adjudicative mechanisms for member rights. It does not prescribe maintenance scheduling. Its principles support asking each RIR to make this recurring operational choice reviewable.

Rights should remain proportionate. A member should not be able to veto security work by asserting unspecified inconvenience. The registry should not reveal other members' sensitive dependencies to explain its balance. Reasoned decisions, aggregate evidence and an appeal against procedure can protect both sides.

Boards should see distribution, not a green average

Governing bodies often receive service availability and change-success percentages. These aggregates can be green while one region repeatedly receives the unfavourable window. Board oversight should include distribution.

A compact maintenance report can show planned and actual duration, notice compliance, affected capability, fallback test result, regional local-time bands, failed transactions, freshness delay, emergency requests, backlog clearance and unresolved actions. Over a year it should show rotation and exceptions. The board need not inspect every routine patch, but it should examine recurring exceptions and material variance.

Targets should resist gaming. If planned maintenance is excluded from availability, publish it separately rather than making it disappear. If a service answering stale data counts as technically available, pair that metric with freshness. If user errors are sampled, disclose the coverage. If a successful change caused substantial retry load, count the user consequence.

Cost decisions belong in the same view. APNIC's 2023 consultation showed that users can value resilience differently and disagree about additional fee investment. A board should explain which availability level it funds, which residual risk it accepts, and why. "Best effort" cannot mean effort that is neither specified nor examined.

Independent audit should sample maintenance evidence: notices, tests, approvals, transaction records and impact calculations. The aim is not to certify that each hour was optimal. It is to test whether the declared procedure was followed and whether management corrected known weaknesses.

Cross-RIR coordination should preserve regional accountability

The Internet Numbers Registry System has five regional operators, not one global maintenance desk. Regional accountability is valuable: members can shape policy and services around different conditions. Coordination should not flatten those differences or create a single correlated point of failure.

Some dependencies are nevertheless shared. RDAP bootstrap and referrals send users across authoritative services. Inter-RIR transfers involve more than one registry. RPKI and reverse DNS have global relying parties. Emergency continuity may require another organisation to operate affected services. Concurrent maintenance can turn individually tolerable degradation into a system problem.

RIRs should therefore exchange a protected calendar of high-risk work, shared-vendor exposure and fallback tests. Public calendars can show material windows without revealing sensitive changes. Coordination rules should prevent avoidable overlap and define which registry leads communication for a cross-regional transaction.

The NRO governance text's continuity provisions address circumstances much more serious than ordinary maintenance, including the possibility of an Emergency Operator. That larger obligation sharpens the smaller lesson: records, systems and procedures should be transferable and tested before a crisis. A registry that cannot explain its read, write and publication dependencies during planned work will struggle to hand them over safely under emergency pressure.

Regional communities should retain the right to examine their RIR's choices. A cross-RIR standard can define minimum evidence, notice fields and coordination duties while allowing each region to set calendars and review routes. Uniform opacity would not be coordination.

A bounded role for Number Resource Society

Number Resource Society can contribute where information and representation are uneven. Smaller operators may know that a window is dangerous but lack a common vocabulary for explaining why. A member organisation can provide a dependency statement template that asks for capability, urgency, fallback, consequence and sensitive handling without demanding unnecessary architecture detail.

NRS could maintain a comparative public register of announced windows, notice lead time, stated service effects, local-time distribution and published post-event reports. The register should reproduce verifiable facts and clearly separate them from NRS assessment. It should not rank registries by raw outage minutes when measurement methods differ.

It could propose a common notice profile and rotation ledger through regional community channels, help operators submit documented comments, and aggregate recurring concerns. Where an operator believes a transaction was mishandled, NRS can help frame the procedural question and identify the registry's complaint route.

The limits are important. NRS does not operate RIR systems and cannot certify that a fallback is independent. It should not collect credentials, confidential change plans or complete incident records. It cannot promise that a registry, arbitrator or court will accept its view. Its own funding and member interests should be disclosed when it comments on fee and resilience trade-offs.

A positive role is thus evidentiary and participatory: make burdens visible, improve the quality of requests, and advocate for reviewable rules. The registry remains accountable for the maintenance decision.

What a fair maintenance standard would require

A practical standard can be concise even if the underlying engineering is complex. Before approval, classify the capabilities affected and their criticality. Map direct and indirect dependencies, including shared vendors. Test fallback against the failure assumption of the change. Select a time using dependency evidence, regional rotation, protected periods and staff readiness. Record exceptions.

Before execution, publish a capability-specific notice through resilient channels. State freshness, transaction handling, alternatives, escalation and recovery. Confirm that monitoring covers significant regions and that the emergency route is staffed. Preserve the pre-change state and transaction boundary needed for rollback.

During execution, watch independent reachability, user errors, freshness, write outcomes, replication, security events and regional concentration. Give an accountable engineer authority to abort. Update the public record when the plan changes rather than waiting for the scheduled end.

After execution, restore all capabilities, clear queues, reconcile uncertain transactions and confirm freshness. Publish expected versus actual duration, affected functions, regional outcome, failures of fallback, emergency use and remedial actions. Protect individual users while preserving enough detail for scrutiny.

Over time, audit rotation, exception patterns, measurement coverage and action closure. Let members challenge inaccurate records and repeated burden through a defined route. Review targets and costs with the community.

This standard does not declare one perfect hour. It requires the institution to make its reasons and consequences legible. That is the enforceable content of fairness.

Evidence limits should shape the claim

Public notices and status histories show what a registry chose to announce. They do not reveal every internal dependency, failed request or user consequence. Quarterly availability reports depend on methods and observation coverage. Consultation responses show the views of entities, not an exact distribution across all number-resource holders.

There is no public, equivalent cross-RIR dataset from 2010 onward that lists every planned window, affected capability, local-time burden, retry outcome and post-event correction. This article therefore does not claim that one RIR is consistently fairer than another or that a particular region has absorbed a measured share of global downtime.

The proposed controls are institutional inferences from public service records, continuity principles and established change-management practice. They should be tested against local law, member agreements, technical architecture and regional governance. A rotation ledger cannot reveal secret dependencies. An emergency route can be abused. Detailed status information can aid attackers if it discloses vulnerable components. Each control needs minimization and access boundaries.

Nor should continuity become an argument against maintenance. Deferred patching, obsolete components and untested recovery can create greater risk. The question is not whether registries may change authoritative systems. It is whether planned risk is reduced, distributed and evidenced rather than assigned by habit.

Twelve clocks, one accountable decision

The engineer looking at twelve local clocks will never find a universally empty hour. That is not a reason to give up on fairness. It is a reason to define fairness correctly.

Dependency determines whose risk is consequential. Redundancy removes risk that need not be allocated at all. Rotation prevents recurring discretionary burden from settling on the same communities. Precise notice lets users protect themselves. Emergency access limits the danger of coincidence. Actual-impact reporting tests whether the institution's assumptions were true. Review and remedy ensure that the next window learns from the last.

The strongest evidence of legitimate maintenance is not that the status page returned to green on schedule. It is that the registry can explain what users could and could not do, why the hour was chosen, which safeguards were tested, who was disproportionately affected, and what changed afterward. Across twelve time zones, the clock is merely the coordinate. Accountability is the service.

Sources