Summary
- A cure period is meaningful only if the holder controls the act needed to cure; it becomes a false deadline when the authoritative error is inside the registry’s own record or process.
- Registry-side data errors should trigger a shared correction file, a temporary safe harbour and a burden rule that prevents shutdown while institutional facts are being reconciled.
- The holder may owe cooperation and evidence, but the registry must carry responsibility for version history, internal logs, matching rules and corrections that only staff can execute.
- Continuity policy should distinguish disputed entitlement from disputed data accuracy, because the first may require adjudication while the second often requires repair of the ledger.
The impossible cure is a governance failure
A cure period assumes that the addressee can do something that changes the outcome. Pay the invoice. Update the contact. Send the corporate document. Remove an unauthorised customer record. Explain a routing change. The deadline is demanding but intelligible because performance lies at least partly within the holder's control.
A different problem arises when the defect is in the registry-controlled record. The holder may be told that its account, organisation name, assignment history, transfer status, contact chain or resource relationship is inconsistent with the registry database. The holder can supply evidence, but it cannot rewrite the authoritative record. It cannot inspect every internal version. It cannot know which staff entry, migration step, legacy import, audit note or reconciliation rule created the mismatch.
In that situation, a cure period can become a ritual of reversed burden. The institution that controls the database identifies a database problem and then tells the holder to cure it under threat of suspension. If the holder cannot disprove an internal inconsistency it cannot see, the institution treats silence or incompleteness as non-compliance. The calendar makes the holder carry the shutdown risk while the registry keeps control of the facts.
The remedy is not to excuse holders from record duties. Accurate registration depends on holder cooperation. The remedy is to classify the problem correctly. Holder-side non-compliance and registry-side data error are different categories. A fair process asks who controls the missing act, who has the evidence, who created the risk and who is able to reduce it before continuity is affected.
A registry database is an operational authority surface
A RIR database is not merely a filing cabinet. It is a public authority surface for network operations. Operators use it to find contacts, validate assignments, interpret route objects, investigate abuse, configure reverse DNS and understand who should answer for a number resource. Other systems draw from it directly or indirectly. Mistakes can travel beyond the registry office.
That authority gives registry data a special character. When the registry publishes a holder, a status, a contact or a resource relationship, outsiders treat that publication as institutionally meaningful. If the record is wrong, the harm is not only private inconvenience. It can misdirect security reports, confuse routing decisions, affect transfer markets, impede due diligence and create evidentiary mistakes in later disputes.
Because the registry owns the authoritative system, it also owns the duty to maintain the integrity history of that system. Version logs, staff actions, migration scripts, legacy imports, supporting tickets, merger approvals and correction notes should not become mysteries when a dispute arises. If the institution cannot explain how a record came to look as it does, it should be cautious about punishing the holder for failing to explain it.
The public nature of the database cuts both ways. Holders cannot ignore stale or false records simply because the registry hosts the system. They benefit from the authority surface and must cooperate. But cooperation is not the same as strict liability for every defect visible in the registry. The more the defect depends on institutional data custody, the more the cure burden must shift back toward the institution.
First ask where the corrective power sits
The decisive question is not who is embarrassed by the error. It is who can perform the correction. A holder can usually correct current contact details, provide documents, identify customers, confirm legal succession and explain present use. A registry must correct internal status fields, historical allocation relationships, staff notes, legacy import errors, resource-link inconsistencies and system-generated restrictions.
Some cases are mixed. A holder may have failed to submit merger documents, while the registry also mapped inherited resources to the wrong account. A customer assignment may be stale because the holder did not report a change, while the registry imported an old entity into a new data model incorrectly. The notice should break the problem into components rather than assign one global cure.
A useful correction table has three columns. The first lists holder-controlled tasks. The second lists registry-controlled tasks. The third lists joint tasks, such as comparing documents to internal history. Each row has its own deadline and consequence. Holder default on one row should not automatically justify revocation when registry-controlled rows remain unresolved.
This allocation of corrective power prevents a common abuse of deadline language. A registry should not say, in effect, prove within a short period that our own record is wrong or lose your resources. The more precise formulation is: provide the documents within your control by this date; the registry will produce and review the relevant record history by this date; no continuity measure will be imposed until the reconciliation file identifies a holder-controlled failure or an urgent risk independent of the data error.
The burden rule should follow information custody
Burden is often described morally: the holder should prove entitlement because the holder claims the resource. That is too simple once the institution's own data is part of the problem. In any record system, the party with custody of a record is normally best placed to explain its provenance. A registry cannot ask a holder to prove a negative against internal material the holder has never seen.
The burden should be divided. The registry should identify the inconsistent record, the rule that makes the inconsistency material, the date range involved and the institutional data on which it relies. The holder should respond with documents, operational facts and corrections within its possession. If the registry relies on internal history, it should disclose the relevant history or provide a reasoned summary where confidentiality requires redaction.
When uncertainty remains after both sides cooperate, the consequence should depend on risk. If the uncertainty concerns a non-operational historical field and no customer or uniqueness risk exists, continuity should remain while the record is annotated or repaired. If the uncertainty concerns possible fraud or competing entitlement, stronger interim measures may be needed. But the reason is then risk, not the holder's failure to cure an invisible record.
A burden rule tied to information custody also improves incentives. Registries maintain better logs when they know those logs will be needed to support enforcement. Holders maintain better documents when they know vague objection will not defeat a clear registry record. Both sides understand that proof is not a weapon to be shifted opportunistically at the end of the process.
Safe harbour protects correction from becoming default
When a holder reports or credibly contests a registry-side data error, the institution should create a temporary safe harbour. The safe harbour does not decide the merits. It prevents the act of seeking correction from becoming evidence of breach and prevents shutdown while the institution investigates a problem it may have created.
The safe harbour can be conditional. The holder must preserve records, stop non-ordinary transfers, maintain contactability, answer targeted questions and avoid using the disputed record to make new claims. The registry must preserve logs, identify responsible staff, suspend destructive changes, keep ordinary operational services running and provide a correction schedule. Both sides can be held to conduct duties.
Safe harbour is especially important where the holder discovers an error that has existed for years. Without protection, reporting the error may trigger enforcement. Rational holders will then delay reporting or try to solve problems informally. That undermines database quality. A registry that wants accurate records should make honest correction safer than silence.
The safe harbour should expire only by reasoned decision. If the registry concludes that the holder caused the defect, the decision should state the evidence. If the registry concludes that the defect was institutional but the holder refuses to cooperate with correction, the consequence should be tied to that refusal. If the cause remains uncertain, the institution should document the uncertainty and choose a continuity-preserving status unless concrete risk justifies more.
Version history is evidence, not housekeeping
Many database disputes turn on time. What did the record show when the resource was allocated? What did it show before a merger? When did a contact change? Which policy version applied? Which staff member approved a status? Which migration transformed the entity? The answer may be buried in logs that were designed for operations, not adversarial review.
A registry should treat version history as governance evidence. That does not mean publishing every internal note. It means preserving enough history to reconstruct material changes and explain them to the affected holder and a reviewer. A record that cannot be reconstructed should be treated as uncertain. It should not be converted into a presumption against the holder merely because the current database has authority.
Version history also protects against hindsight. A field may look obviously wrong under today's structure because the data model changed. Legacy records may have used looser organisation names, different address formats, manual notes or conventions that no longer exist. The question is not whether the old record would pass a modern form validator. It is whether the holder breached an obligation under the applicable rule and whether correction is now required.
The notice should therefore cite the relevant record versions, not just the current discrepancy. If the registry cannot cite them, it should say what it can and cannot reconstruct. That candour may weaken a dramatic enforcement case, but it strengthens the legitimacy of the correction process. A database that admits uncertainty is more trustworthy than one that claims perfect memory after migration.
Registry error should not become customer outage
The worst version of reversed burden occurs when a registry-side data problem threatens customers. A holder may be told that because the registry questions a historical record, resources will be deregistered unless the holder resolves the matter quickly. Customers then face uncertainty because two institutions disagree about a ledger. That is a poor allocation of operational risk.
Continuity should be the default while a registry-side error is being evaluated. The registry can mark the record as under review, restrict transfers, require customer notification where appropriate and accelerate evidence exchange. It should avoid measures that cause customers to lose contactability, reverse DNS, route-origin support or confidence in the holder's status unless there is independent evidence of immediate harm.
Customer protection is not a gift to the holder. It protects users and operators who relied on the public registry. If the registry later proves that the holder was never entitled to the resources, transition may still be necessary. The point is that transition should be planned from a verified entitlement decision, not improvised from a data mismatch.
This principle also discourages strategic ambiguity. If holders know that customers will not be used as hostages in a record dispute, they have less reason to escalate theatrically. If registries know that continuity is expected during institutional correction, they have more reason to invest in evidence before threatening shutdown. The system becomes less dramatic and more accurate.
Correction is different from adjudication
Not every data dispute is an entitlement dispute. Some are correction cases: a name is wrong, a contact is stale, a legacy link is missing, a system migration created duplicates, a status did not carry over or a staff note was attached to the wrong account. The remedy is repair. Other cases are adjudication cases: two entities claim the same resource, documents are alleged to be forged, the holder may be outside the permitted relationship or a transfer may have been invalid. The remedy may require a decision on rights.
Confusing the two categories distorts notice. Correction cases need access to records, technical staff and a practical repair timetable. Adjudication cases need evidence disclosure, decision-maker authority, interim protection and appeal. A single cure period cannot serve both functions unless it clearly separates them.
The notice should state which category the registry believes it is in and why. If the category changes as evidence develops, the registry should issue an updated notice. That update is not weakness. It shows that the institution is following the facts rather than forcing every problem into the first procedural box selected.
This classification also helps reviewers. A reviewer should not ask whether the holder cured if the real issue was whether the registry had corrected its own record. Nor should a reviewer treat a genuine entitlement conflict as a mere clerical issue. The standard of review, the evidence required and the acceptable interim measures all depend on the type of problem.
The holder still has duties
A registry-side error rule should not become a holder excuse. Holders must keep documents, maintain contacts, respond to specific questions, identify current legal status and avoid opportunistic reliance on known mistakes. If a holder knows that a record incorrectly expands its rights, the holder should not exploit the error while demanding safe harbour.
The holder's duties should be specific. Preserve correspondence. Produce corporate succession documents. Identify operational customers affected by correction. Explain any known discrepancy between public registration and actual use. Confirm whether transfers or assignments occurred during the disputed period. Nominate a person with authority to resolve the correction file.
Failure to perform those tasks can justify escalation, but the escalation should match the failure. Refusing to provide merger documents may support adverse inference on legal continuity. Failing to update an abuse contact may support contact restrictions. It does not automatically prove that the registry's historical allocation record is correct. The remedy should remain connected to the holder-controlled duty that was breached.
This balance matters for credibility. If the article's argument were simply that the registry must fix everything, it would be as one-sided as the reversed-burden problem it criticises. The better rule is reciprocal: each side carries the burden for the facts and actions it controls. Continuity is protected while that allocation is being tested.
A correction file should be structured before sanctions
Before sanction, the registry should open a correction file with a clear structure. The file identifies the disputed record, the affected resources, the date range, the registry-controlled evidence, the holder-controlled evidence, the operational risks, the interim restrictions and the decision path. It should be shared in a form the holder can answer.
The file should include a status statement for each contested item: confirmed registry error, confirmed holder error, shared uncertainty, pending evidence or irrelevant to remedy. This prevents one unresolved item from contaminating the whole relationship. It also lets the registry correct what is already clear while preserving disputed items for review.
The file should have deadlines, but they should be functional. A holder may have ten business days to acknowledge, a longer period to produce archived documents and immediate duties to preserve or stop transfers. The registry may have its own deadlines for log extraction, staff interview and preliminary correction. Deadlines should apply to the institution as well as to the holder.
Only after the correction file identifies a holder-controlled failure, a non-curable entitlement defect or an urgent risk should the registry move toward revocation. That sequence turns the cure period back into what it claims to be: an opportunity to correct the real problem, not a countdown attached to an unresolved institutional record.
Public transparency can preserve trust without exposing private files
Registry-side errors are embarrassing. Institutions may prefer to resolve them quietly. Some discretion is necessary because holder files contain private business information. But a registry that never reports categories of institutional error leaves the community unable to distinguish isolated correction from systemic weakness.
An anonymised transparency report can list record-error categories, age of errors, correction times, number of continuity-protected cases, number of holder-caused cases and number of cases escalated to sanction. It can describe improvements to logging, migration review and staff approval. It need not expose names, customers or disputed documents.
Transparency also helps prevent selective enforcement. If a registry has tolerated a data problem across many accounts, it should be cautious about immediate sanction against one holder without explaining why that case is different. Conversely, if a holder tries to portray a routine correction as institutional collapse, aggregate reporting can show the scale.
The public should not have to choose between blind trust in the registry and blind trust in the holder. A structured correction practice lets the institution admit fallibility while preserving authority. In a system built on accurate shared records, that admission is not weakness. It is part of the maintenance function.
A cure period must be able to cure
The rule can be stated plainly: do not threaten revocation through a cure period unless the cure demanded is within the holder's power or the institution has committed to performing its own part of the correction during the same period. A deadline without corrective agency is not due process. It is pressure.
The better notice says what the holder must do, what the registry must do, what remains uncertain, what will happen during review and what event will justify escalation. It treats the database as a shared operational dependency with an authoritative custodian, not as a neutral fact that always speaks against the holder.
This approach protects the registry's legitimacy. It reduces the chance that courts or community reviewers see enforcement as arbitrary. It encourages holders to report errors. It preserves customer continuity while facts are reconciled. It also makes sanctions stronger when they are finally imposed, because the institution can show that the problem was not its own uncorrected record.
A cure period that cannot cure the database should never be the path to shutdown. If the database is wrong, repair it. If entitlement is disputed, decide it on a disclosed record. If urgency exists, prove it and tailor the interim measure. What should not happen is the quiet reversal of institutional burden onto the one party least able to fix the authoritative ledger.
Status annotations can protect reliance while facts are checked
A registry does not have only two choices, silent continuity or revocation. It can annotate status. A public or member-visible status note can say that a record is under review, that transfers are restricted, that contact correction is pending or that a historical relationship is being reconciled. The wording must be careful, but annotation is often better than pretending certainty exists.
Status annotation protects outsiders without deciding the dispute. A buyer, customer, security team or peer can see that the record needs caution. The holder remains able to maintain ordinary operations. The registry preserves the resource from opportunistic movement while it investigates. Reviewers can see that the institution chose a measured interim step.
Annotation can be abused if it becomes defamatory or indefinite. The registry should define categories, review dates and expiry rules. It should avoid language that declares fraud before a decision. It should remove or update the note when the correction file closes. The holder should have a channel to challenge wording that overstates the case.
Used properly, annotation is a continuity tool. It recognises that registry data is relied on by the public and that sudden deletion may be more harmful than visible uncertainty. It also prevents the holder from using an unresolved record as if no question existed. The system speaks honestly: the record remains authoritative, but this part of it is being examined.
Migration errors need their own audit trail
Many registry databases have passed through migrations: new software, new entity models, new authentication systems, legacy imports, mergers of older records and changes in publication format. Migration is a normal part of maintenance. It is also a common source of disputes because old assumptions become new fields.
A holder should not be sanctioned merely because a migrated record looks inconsistent under a later model. The registry should first ask whether the inconsistency existed in the old system, whether the migration transformed it, whether staff made manual choices and whether the holder had any opportunity to verify the transformed record. The answers belong in the correction file.
Migration audit trails should include mapping rules, exception reports, manual overrides, validation warnings and notices sent to holders. If the registry lacks those materials, it should treat the resulting uncertainty as institutional uncertainty. That does not decide entitlement in favour of the holder, but it counsels against severe sanction without other proof.
The lesson is broader than one migration. Data governance is enforcement governance. A registry that wants strong remedies later must keep enough history now. Otherwise the institution may discover that its own maintenance process has made the decisive facts unprovable.
The reviewer should ask who created the uncertainty
When a database dispute reaches review, the first question should be causal. Who created the uncertainty? The holder may have failed to update a record, supplied inconsistent documents or ignored verification. The registry may have imported data wrongly, lost history, merged accounts or changed fields without clear notice. Sometimes both contributed.
This causal question should shape remedy. Holder-created uncertainty can justify adverse inference, tighter deadlines or restrictions. Registry-created uncertainty should justify safe harbour, institutional correction and reluctance to impose irreversible consequences. Shared uncertainty should produce shared tasks, not automatic shutdown.
The reviewer should resist the temptation to say that the current database is authoritative and therefore conclusive. Authority makes the database important; it does not make it infallible. The whole point of review is to test whether the authority surface accurately reflects the underlying relationship. A conclusive presumption would make correction impossible precisely when correction is needed most.
A causal uncertainty analysis also improves future practice. If the registry repeatedly creates uncertainty through one field or process, it can fix that process. If holders repeatedly create uncertainty through poor documents, the registry can tighten onboarding. The review becomes institutional learning rather than a one-off allocation of blame.
Customer notice should be controlled and factual
When a database correction may affect downstream users, customer notice becomes delicate. Too little notice leaves customers surprised. Too much accusatory notice can destroy trust before facts are settled. The registry and holder should agree, or the reviewer should approve, a controlled factual notice when customer action may be needed.
The notice should identify the operational issue, the records being reviewed, the interim status and the steps customers should take to preserve service. It should avoid declaring breach unless breach has been decided. It should provide a published contact points. It should make clear whether routing, reverse DNS or resource certificates are expected to change during the review.
The holder may want to minimise the issue; the registry may want to warn broadly. A controlled notice balances those interests. It protects customers without converting a data dispute into a public sanction. It also prevents later claims that customers were used as surprise leverage.
Customer notice should be proportional. A minor internal correction may not require any customer message. A potential change in resource status may require direct communication. The decision should be recorded. In all cases, customer reliance should be treated as a reason for careful management, not as a rhetorical prize for either side.
Correction metrics should sit beside enforcement metrics
A registry that reports only enforcement outcomes creates an incomplete picture. It may say how many accounts were closed or how many resources were recovered. It should also say how many records were corrected, how many corrections came from holder reports, how many came from registry audits and how long correction took. Correction is a success metric.
Those metrics change incentives. Staff who find and repair institutional errors should not appear to have created problems; they should be credited for improving the ledger. Holders who report errors should see that the institution values correction. Members can judge whether the database is becoming more accurate over time.
Correction metrics also reveal bottlenecks. If legacy records take months to reconcile, the registry may need archival investment. If contact corrections are fast but status corrections are slow, the problem may be approval authority. If many corrections require legal review, agreements may need clearer succession rules.
Publishing correction metrics does not weaken enforcement. It shows that sanctions are not the only tool. A registry's legitimacy comes from accurate stewardship. Sometimes stewardship means removing a bad claim. Sometimes it means admitting that the authoritative record needed repair.
The ledger is authoritative because it can be corrected
Authority and correction are not opposites. A registry database is authoritative because the community trusts the institution to maintain it, including by correcting mistakes. If the registry treats every challenge as an attack on authority, it misunderstands the source of that authority. Trust comes from disciplined fallibility.
The cure-period problem exposes the misunderstanding. The institution sees an inconsistency in the ledger and turns immediately to holder default. A more confident institution asks whether the ledger itself needs work. It can still enforce against bad holders. It simply refuses to confuse its own record with reality when evidence suggests the two may diverge.
This is especially important as address resources become more valuable. The temptation to treat the current database as dispositive will grow because value creates disputes. But value also raises the cost of error. A mistaken shutdown, mistaken transfer block or mistaken public status can affect businesses and customers far beyond the original record.
A cure period can cure only what the addressee can change. When the authoritative database is the thing that needs correction, the registry must join the cure. That is not concession. It is the maintenance obligation that makes registry authority worth having.
Correction channels should be easier than escalation channels
If correcting a registry-side error requires extraordinary escalation, the system will accumulate avoidable disputes. Holders should not need a lawyer, board contact or public campaign to repair an obvious mismatch. The registry should provide a defined correction channel with intake, case number, evidence list, expected response time and escalation path when ordinary support cannot resolve the issue.
The channel should distinguish urgent operational errors from ordinary maintenance. A wrong abuse contact may be important but not always urgent. A mistaken resource status, broken reverse DNS delegation or incorrect legal holder can require faster review. The intake form should ask about operational impact without making the holder prove catastrophe before staff looks at the record.
An accessible correction channel also improves enforcement. When a holder later says the database was wrong, the registry can ask whether the holder used the channel and supplied evidence. When the registry failed to answer, that failure becomes visible. Both sides gain a cleaner record than scattered emails and informal calls.
The best correction systems are boring. They make repair routine, not dramatic. That is exactly what an authoritative registry should want. If correction is ordinary, sanction can be reserved for refusal, fraud and unresolved entitlement disputes rather than for records that never had a practical path to repair.
Legacy resources need special caution
Legacy resources make database correction harder. Some records predate current membership agreements, current authentication models, current corporate forms or even the existence of the present registry. Documents may be old, incomplete or held by successor entities. A modern database may contain fields that legacy allocation records never contemplated.
A registry should not use modern neatness as the standard for legacy truth. It should ask what evidence would reasonably exist for the period, what public records corroborate the relationship, what operational continuity has occurred and whether any competing claimant exists. The holder should cooperate, but the institution should recognise archival limits.
Legacy uncertainty can justify annotation, transfer caution and documentation requests. It does not automatically justify revocation. The risk of error is high when the record is old and the registry's own succession history is part of the chain. A cure period that demands modern proof for an old record may be impossible by design.
Careful legacy handling protects the whole community. Many early allocations became embedded in networks, customer relationships and security processes long before current compliance forms existed. Correcting those records is necessary. Treating archival gaps as immediate holder fault is not.
The final question is operational agency
Every database cure dispute should end with one question: who has operational agency to fix the defect now? If the holder can fix it, give a clear order and a reasonable deadline. If the registry can fix it, do so and record the basis. If both must act, split the tasks. If neither can fully resolve historical uncertainty, choose a continuity-preserving status unless independent risk justifies restriction.
This agency question keeps the process honest. It prevents the registry from exporting its own uncertainty. It prevents the holder from using institutional fallibility as an excuse for refusing cooperation. It forces the remedy to match reality rather than institutional convenience.
A database is authoritative because the community needs one place to look. That authority carries a duty to repair the place people look. A cure period that cannot cure the authoritative record is not merely unfair to one holder. It weakens the reliability of the registry for everyone who depends on it.
A correction-first culture is cheaper than a sanction-first culture
Correction-first governance is not sentimental. It is cheaper, faster and more reliable than sanction-first governance for data errors. A sanction-first culture treats every discrepancy as a possible enforcement opportunity. Staff draft threatening letters, holders seek counsel, customers worry, reviewers are drawn in and the underlying record may still remain wrong. The institution spends authority before it has repaired the fact base.
A correction-first culture asks whether the authoritative record can be made accurate with cooperation. It opens the correction file, allocates tasks by control, protects continuity, and escalates only when the holder refuses, the evidence shows entitlement failure or urgent harm appears. Many cases will end there. The registry gets a better database. The holder gets a clearer obligation. Customers never see a crisis.
This culture requires management support. Staff should not fear that admitting a registry-side error will be treated as failure. The failure is leaving the error uncorrected or using it to justify an avoidable shutdown. Internal metrics should reward timely correction, clean logs and candid uncertainty. Legal teams should help structure safe acknowledgement rather than insisting that every institutional mistake remain unstated.
It also requires holder discipline. A correction-first process is not an invitation to bury the registry in vague allegations. The holder should identify the precise record it contests, the correction sought, the supporting evidence and the operational impact. It should preserve the status quo while the file is open. It should not use an institutional error as cover for unrelated non-compliance.
The payoff is trust in the ledger. Operators do not expect any large registry database to be perfect forever. They do expect the authority that maintains it to have a fair way to fix mistakes. When correction is visible and routine, the database becomes more credible, not less. When every error becomes a fight over blame, the database becomes brittle. The cure period should be part of the correction system. If it is used instead to shift institutional uncertainty onto the holder, it is not curing the database. It is protecting the appearance of certainty at the expense of accuracy.