Portable Registration in Seven Steps

Summary

• Portable registration should change the qualified provider serving a recognized holder, not the holder, resource, allocation history or routing policy. If holder identity also changes, that is a separate transaction with separate authority and evidence, even when both changes are scheduled near each other.
• The seven steps are request, verification, notice, parallel run, cutover, proof and dispute isolation. Every step has a version-bound input, responsible role, deadline, signed result and defined failure state so an independent reviewer can reconstruct the switch without relying on one provider's narrative.
• The gaining provider authenticates the holder and assembles the request. An independent coordination function verifies current state, provider qualification, authority, scope and holds. The losing provider receives notice and may entity only on published, evidenced grounds; silence and unrelated fee disputes do not become permanent vetoes.
• A parallel run prepares records, contacts, monitoring and dependent services without creating two current authorities. The old provider remains able to perform current acts until cutover; the new provider can validate and stage changes but cannot commit them. Mirrored observation is allowed. Dual control is not.
• Cutover is one ordered event that activates the new provider and retires the old provider's current authority against the same resource version. RDAP discovery, reverse DNS, RPKI arrangements, recovery channels and emergency contacts require explicit continuity choices rather than an assumption that one registrar pointer changes everything safely.
• Proof consists of independently verifiable receipts, before-and-after state, dependency checks and notices to the holder and both providers. It should establish what changed and what did not, while protected authentication evidence remains confidential.
• Dispute isolation prevents one contested resource, provider or dependent service from freezing clean switches or forking authority. A challenge receives a narrow hold, preserved evidence, reasoned review and bounded remedies; the undisputed portfolio and the one-current-state rule continue.

Portability needs a procedure, not a principle alone

An institution can proclaim a right to exit while making exit impractical. The current provider may control credentials, evidence, private contacts and dependent services. Its staff may treat every request as exceptional. The receiving provider may not know which records are authoritative. A common coordinator may accept instructions without exposing its decision sequence. In that environment, portability exists in policy and fails in practice.

The opposite error is to reduce switching to one database field. Number registration sits beside several systems with different meanings and clocks. RDAP helps users discover registration information. Reverse DNS delegates naming under address space. RPKI supports signed routing authorization. Routing itself remains a decision of networks. A provider change can affect none, some or all of these, depending on the service arrangement.

A serious procedure must therefore be both narrow and complete. Narrow means the base act changes only the registration-service provider. Complete means every dependency is inventoried and given an explicit transition decision. The holder should not discover after cutover that the old provider retained an account-recovery channel or that a hosted RPKI arrangement stopped publishing.

Replayability is the test. An independent reviewer should be able to take the preserved request, current-state reference, verification result, notices, staged dependency plan, cutover receipt and later objections, then reproduce the reason each state was accepted. If the explanation depends on unwritten staff memory, the right to switch remains discretionary.

The invariant is one holder, one resource state, one current provider

The seven steps begin with an invariant. For each covered resource at any accepted version, there is one recognized holder and one current registration-service provider. Historic providers remain visible. Proposed providers can prepare. Witnesses can hold replicas. None may publish a rival current answer as equally authoritative.

This principle follows the uniqueness concern documented in RFC 7020. Globally coordinated IP address space and autonomous system numbers lose operational meaning if different institutions can allocate or recognize the same resource incompatibly. Competition should occur around service, not around contradictory current states.

The invariant does not require one central company or one machine. Independent validators can witness a transition, and several sites can serve the accepted record. What matters is ordered convergence. A request references a current version. A successful cutover consumes that version and creates one successor. A stale or conflicting request fails safely rather than creating a branch.

The invariant also clarifies the parallel run. Both providers may possess data and observe test results. Only one has current authority to submit ordinary changes before cutover, and only the other has that authority after cutover. Preparation can overlap; authoritative control cannot. This boundary allows continuity without turning a service transition into a contest over which provider's record the public should trust.

Provider switching must be separated from holder transfer

A service switch keeps the recognized holder unchanged. The legal name, holder reference, resource set, allocation history, existing restrictions and unresolved claims carry forward. The receiving provider accepts responsibility for future registration service. It does not acquire the resource or reopen the holder's eligibility as if a new allocation were being made.

A holder transfer changes the recognized person or organization. It may arise from sale, merger, insolvency, succession or policy-based transfer. That act requires evidence from the current holder and proposed holder, substantive eligibility review where applicable, and treatment of related rights and restrictions. Hiding it inside portability would weaken both security and market accountability.

The request must explicitly state the invariant fields. It should say that the holder is unchanged, list the exact resources, identify the current provider and name the proposed provider. If the holder's legal identity changed through merger or conversion, the request either cites a previously accepted continuity decision or enters the holder-change procedure first.

Two transactions can be coordinated without being merged. A company being acquired may wish to change provider on completion. The holder-change decision can be conditional, and the provider switch can be scheduled immediately afterward. Each still has its own authorization, evidence and result. If the acquisition fails, the holder can retain its independent right to leave the old provider. If the provider switch fails, the acquisition is not falsely treated as invalid.

Six roles make responsibility visible

The holder initiates and authorizes the switch. Its representatives must have authority for the covered resources and the consequences requested. The gaining provider authenticates the holder, assembles the submission, validates service readiness and accepts future duties.

The losing provider preserves current service, provides required export, sends independent notice, identifies valid objections and retires authority at cutover. It does not judge the gaining provider's commercial merits or use unrelated debt as a general veto.

The coordination function checks the current version, provider qualification, authorization result, holds, timing and dependency declarations. It commits one ordered provider substitution. The dependency operators manage RDAP publication, reverse DNS, RPKI hosting, monitoring or other services that may or may not move with the base registration.

The independent reviewer examines contested verification, invalid objections, unauthorized cutover and continuity failures. It needs access to preserved evidence and power to order narrow restoration, correction or compensation without becoming the routine operator.

One organization may perform several roles, but each act should be logged under the role that authorized it. If the Society both coordinates and reviews, internal separation is not enough for high-impact disputes; an outside review path is required. Role clarity prevents every failure from being assigned to an abstract “system” and prevents the current provider from claiming that its customer relationship gives it authority over the common state.

A replayable transition has a small common record

Every switch should have a durable transition record. It identifies the resource set, recognized holder, old and new providers, referenced current version, requested date, authority class, dependency plan, applicable holds, notices, decisions and resulting version. Each event records responsible role, time, result and evidence reference.

The record should contain enough information to replay decisions without exposing unnecessary personal evidence. A reviewer can see that a qualified verifier confirmed holder authority at a stated assurance level and inspect the protected evidence under controlled access if the confirmation is challenged. Public observers need the switch status and event times, not identity images or private contracts.

The state vocabulary should be finite: requested, verification pending, verified, notice open, parallel preparation, ready, cutover committed, proof complete, disputed, isolated and closed. Failure states should identify the failed step rather than returning the resource to an ambiguous general queue. A missing reverse-DNS test is different from failed holder authentication.

Version binding prevents replay attacks and accidental duplication. If a contact, hold or holder record changes after verification, the coordination function compares the new state with the request. A material change sends the transition back to the relevant step. An immaterial update can be recorded without restarting everything. The reason must be visible so providers cannot selectively call inconvenient changes material.

Step 1: Request

The holder begins with the gaining provider, not by negotiating release with the incumbent. That reduces captivity and gives the provider seeking the business responsibility for assembling a complete request. The holder identifies the exact resources, current provider, desired switch date, representatives, preferred notice channels and every dependent service known to be supplied by the old provider.

The request declares what will not change: recognized holder, resource scope, allocation history and existing dispute restrictions. It also declares whether billing, managed RPKI, reverse DNS, RDAP presentation, abuse contacts, delegated administration, monitoring or recovery arrangements should move, remain or end. Unknown dependencies are marked for discovery rather than silently assumed absent.

The gaining provider returns a signed receipt with a transition reference, normalized resource list, current-state version and expiry. The holder can detect omissions before authentication evidence is submitted. Duplicate requests for the same resource and version are linked; they do not create competing races among gaining providers.

The request can be withdrawn until the cutover commit, subject to notice and preservation. Withdrawal should not expose the holder to a penalty from the old provider beyond disclosed costs actually incurred. A fresh request is required after expiry or a material holder change. This protects against an old authorization being used months later when representatives or corporate control have changed.

Step 2: Verification

The gaining provider verifies that the requester represents the current holder and is authorized to change registration service for the listed resources. It checks the holder's current control claim, representative powers, independent contact confirmation and any enhanced requirements for high-impact resources. Authentication to an account is evidence, not the whole decision.

The coordination function separately verifies the current state. It confirms that the holder and resource set match the authoritative record, the old provider is current, the new provider is qualified for the service class, the request version remains fresh and no incompatible hold exists. This second check prevents a gaining provider from validating its own commercial conclusion as common authority.

Verification should identify dependencies that can create hidden vetoes. If the old provider hosts RPKI, controls reverse delegation or holds the only recovery contact, the transition plan must address each before readiness. A service is not treated as inseparable merely because the incumbent bundled it. The holder chooses a continuity option under published technical constraints.

The result is a signed verification statement with scope, assurance, evidence dates, exceptions and expiry. Failure carries a reason: wrong holder, limited public evidence authority, resource mismatch, unqualified provider, active stay, stale state or unresolved dependency. The holder can correct evidence or seek review. The verifier may not return an unexplained denial that forces the holder to guess which fact failed.

Step 3: Notice

After verification, the coordination function sends notice through at least two independent paths: to the holder's protected contacts and to the losing provider's designated transition contact. The gaining provider receives the same event. Notice identifies the resources, unchanged holder, proposed provider, scheduled window, objection deadline and protected challenge route.

The losing provider may entity only on published grounds supported by evidence. Valid grounds can include a credible unauthorized request, a mismatch in holder identity, a binding court or review stay, a current fraud investigation under defined authority, or a resource outside the holder's control. Dissatisfaction with competition, bundled-service loss, ordinary contract debt or preference for another provider should not block the base switch.

Silence has a defined consequence. Once required notice was delivered and the objection period expired, the transition continues. Incumbent inaction cannot become a permanent veto. At the same time, notice should not be so short that a compromised account can move a portfolio before an independent contact responds. Timing should reflect risk, with emergency recovery for strong evidence of theft.

The holder can choose a later cutover date within a permitted window. Public-sector and critical networks may need maintenance coordination. A valid objection does not decide the merits automatically; it moves the affected resources to dispute isolation while clean resources proceed. Notice is therefore both a security control and a branching point that contains conflict.

Step 4: Parallel run

The parallel run prepares the new service while the old provider remains current. The gaining provider imports permitted registration data, configures contacts, validates resource scope, stages monitoring and tests its ability to submit changes. Dependency operators prepare replacement or continuing arrangements. The holder reviews a comparison of old and proposed states.

This stage must prohibit dual write authority. The new provider cannot commit current holder, contact, transfer or security changes. It works in a non-authoritative state and records proposed differences. The old provider continues current duties and may not degrade service merely because a verified switch is pending.

Read-only comparison is valuable. Both providers can calculate the expected post-cutover RDAP result, verify that every prefix and autonomous system number is present, confirm notice contacts and test response endpoints. Independent observers can compare state digests. Differences are classified as intended, harmless formatting, missing data or blocking conflict.

Parallel time should be bounded. A minimum permits meaningful checking; a maximum prevents the old provider from extending dependence through endless readiness demands. Simple portfolios may need hours. Complex public networks may need several days or a scheduled maintenance period. The standard should set classes and allow justified variation.

The output is a readiness statement signed by the gaining provider, acknowledged by the holder and checked by coordination. It lists unresolved non-blocking issues and the exact cutover plan. If readiness fails, the old service continues and the transition returns to the failed preparation task rather than losing its verified history.

Step 5: Cutover

Cutover is one ordered commit against the verified current version. The coordination function checks that the notice period closed, no new incompatible hold exists, readiness remains valid and the scheduled time has arrived. It then activates the gaining provider's current authority and retires the losing provider's authority in the same accepted event.

There must be no gap in which neither provider can perform urgent service and no overlap in which both can commit. Distributed validators may witness or co-sign the event, but they accept one sequence. A late conflicting instruction from the old provider fails against the superseded version. A pre-submitted instruction from the new provider cannot take effect before the commit.

Cutover should change only fields authorized by the request. The provider reference, provider-scoped recovery keys and selected service endpoints may change. Holder identity, resource range, allocation history, standing restrictions and unrelated contacts remain unless a separate approved change says otherwise. A before-and-after comparison makes unauthorized extras visible.

If the commit cannot achieve atomic authority, it fails closed before either provider state changes. Recovery should use the last accepted current version, not an improvised choice by whichever provider responds first. For a large portfolio, resources can be partitioned into declared groups, each with its own commit, so one malformed record does not create an all-or-nothing regional event.

Step 6: Proof

Completion requires more than a success message from the gaining provider. The coordination function issues a signed receipt identifying the prior and new versions, exact resources, old and new providers, cutover time, unchanged holder and any dependency events. Independent witnesses publish or retain verifiable confirmation of the accepted sequence.

The holder receives a human-readable comparison and machine-verifiable receipt. The losing provider receives proof that its current authority ended and a list of continuing duties, such as evidence retention or final export. The gaining provider receives proof that its authority began. Public registration shows the current provider and an event history appropriate to the service.

Dependency proof is explicit. RDAP queries are tested through authoritative discovery. Reverse DNS delegation is checked from relevant public points. RPKI publication and relying-party visibility are observed according to the selected continuity plan. Recovery contacts are challenged through approved channels. A routing observation can show operational continuity but is not required to declare the registration commit valid.

Proof has a time window because distributed caches and repositories do not change instantaneously. The receipt distinguishes “commit accepted” from “all observations complete.” Delayed observation creates a remediation task and, where risk requires, a targeted safeguard. It does not permit the old provider to revive current authority unilaterally.

Step 7: Dispute isolation

A dispute after or during switching should be isolated by resource, issue and authority. If one prefix in a portfolio is subject to a court stay, that prefix can remain with the current provider while unrelated prefixes proceed. If only reverse DNS failed, the registration-provider commit need not be reversed automatically. If holder authorization is credibly challenged, high-consequence actions can be held while ordinary continuity remains.

Isolation begins by preserving the relevant request, evidence, notices, state versions and dependency observations. The reviewer identifies the contested proposition: holder identity, representative authority, provider qualification, notice delivery, cutover ordering or service continuity. Remedies then target that proposition.

An unauthorized switch may justify restoring the prior provider through a new ordered commit, not rewriting history as if the event never occurred. A provider error may require correction and compensation. A notice defect may require renewed confirmation without disturbing a clearly authorized holder. A dependent-service outage may require temporary technical restoration while registration authority stays with the new provider.

The dispute record must not create rival public states. A “disputed” marker can warn relying parties while one current provider remains identified. Review deadlines, interim protections, reasoned decisions and appeal prevent a temporary hold from becoming quiet permanent captivity. Other clean transitions continue. Isolation is what allows due process and operational continuity to coexist.

Domain transfers show why gaining and losing roles differ

ICANN's Transfer Policy offers a useful institutional comparison. It distinguishes the gaining registrar, registrar of record and registry operator; assigns authorization duties; limits reasons for denial; requires notices; and provides a dispute route. The policy has evolved and remains specific to domain names, but its role separation demonstrates that provider choice does not require competing authoritative registries.

Number resources differ materially. A domain transfer changes sponsorship for one name under a registry. An IP prefix or autonomous system number may carry reverse delegation, RPKI objects, public routing observations, sub-delegations and scarcity-sensitive market relationships. A number holder may also have a portfolio that spans many operational units.

The lesson is therefore procedural, not literal. The gaining provider should bear the burden of authenticating and submitting a complete request. The losing provider should receive notice and have bounded objections. A common authority should perform the provider substitution. Evidence should be retained for disputes. Unrelated fee disagreement should not become a general lock on exit.

The domain experience also shows that credentials alone are not authorization. A transfer code can connect a request to a registration, but holder confirmation and policy checks remain necessary. Number portability should use strong, resource-specific credentials without pretending that possession of a secret proves current corporate authority.

Mobile number portability shows the value of a customer-controlled start

Ofcom's current consumer guidance explains that a mobile customer can obtain a switching code and give it to the new provider, which notifies the current provider; the number should normally be ported within one working day. The framework also addresses double charging and compensation for delay. This is not a model for the legal status of Internet number resources, but it shows the value of a clear customer action, receiving-provider responsibility and measurable completion time.

The strongest comparison is the direction of travel. The customer approaches the provider it wants, rather than asking the provider it wants to leave to manage the whole switch. A code gives the receiving provider a portable reference. The providers coordinate under common rules. The customer keeps the identifier.

Number registration needs more evidence and longer risk classes for some changes, but it should preserve the same institutional discipline. The holder starts with the gaining provider. The old provider supplies required continuity and can raise defined security objections. It does not control whether competition is allowed.

Compensation also matters. A right without consequences for unreasonable delay can become nominal. Service standards should provide automatic fee relief or defined compensation for provider-caused delay, while separately preserving remedies for consequential high-control failures. Speed should never excuse weak authorization, but “security review” should not become an unmeasured category with no end.

Current-account switching shows why redirection and guarantees matter

The United Kingdom's Current Account Switch Service was introduced with a seven-working-day switch, customer-selected timing, a guarantee against certain losses and redirection of payments sent to the old account. Banking is not number registration, and financial transfers have distinct law and risk. The comparison is useful because it treats switching as continuity infrastructure rather than a bilateral cancellation.

The equivalent of payment redirection is not route redirection. Networks, not registrars, decide where packets travel. The transferable lesson is that stale counterparties and delayed updates should be anticipated. Notices sent to the old provider, obsolete published contact points or requests addressed to a former service endpoint can be forwarded or answered with a signed referral for a bounded period.

The guarantee lesson is also institutional. The holder should not bear every cost caused by providers failing to execute the common procedure. Defined service credits, correction duties and higher responsibility for unauthorized changes create incentives to maintain readiness. The guarantee should match controllable harms rather than promise that no remote network will ever suffer loss.

Finally, customer-selected timing matters for public-sector and critical networks. A holder may avoid a fiscal close, election period, public-service peak or planned infrastructure change. Portability should provide bounded choice of cutover window after verification, not force every holder into the first available automated slot.

RDAP continuity requires discovery, content and history checks

RDAP portability has three layers. First, clients must reach the authoritative service through the applicable discovery arrangement. Second, the new response must contain accurate holder, network, autonomous system, contact, status, notice and event information. Third, the history must explain the provider transition without inventing a new resource identity.

RFC 9083 supports structured entities, roles, events, notices, remarks and statuses. A switch can therefore be represented as a service event while the holder and resource entities remain continuous. The gaining provider may improve presentation, but common semantics must survive.

Parallel preparation should compare the old public response with the proposed response field by field. Intended privacy differences, localized presentation and provider contacts can be approved. Missing resource ranges, altered holder names, lost notices or removed status constraints should block readiness. Proof should query through normal discovery rather than only a private endpoint supplied by the new provider.

Caching and distributed observation require patience. A correct authoritative change may not appear everywhere instantly. The procedure should define expected windows and distinguish cache delay from wrong referral. The old service can return a bounded referral after cutover, but it must not continue presenting itself as an equally current authority.

Reverse DNS should move only under an explicit option

Reverse DNS is operationally important but conceptually separate from the registration provider. Some holders may keep existing name servers. Others may use provider-hosted service and need to migrate. Still others may delegate portions to customers. A base provider switch should not silently rewrite the delegation.

The request lists the current arrangement and selects retain, migrate or separate later change. Retain means the gaining provider verifies that the delegation can continue after the old commercial relationship ends. Migrate means new authoritative servers are prepared, zone data is validated, time-to-live planning is considered and the delegation change is authorized. Separate means the switch completes while a protected later task handles DNS.

Parallel run can test the new servers and compare responses without making them authoritative. Cutover may coordinate the delegation event if the holder chose migration, but the event remains separately visible. Proof checks the delegation from multiple public perspectives and verifies expected records.

Failure isolation is crucial. A reverse-DNS error should trigger technical restoration or correction, not create two registration providers. The old provider may have a bounded duty to preserve service during an agreed transition, especially where it controlled the only prior hosting. That duty should be priced and disclosed before the holder requests exit, not improvised as leverage afterward.

RPKI continuity needs a separate authority plan

RPKI is the most security-sensitive dependency because signed entities can influence route-origin validation by relying networks. RFC 6480 describes a resource public key infrastructure, signed routing entities and distributed repositories. RFC 9582 specifies the current Route Origin Authorization profile. A registration-provider switch must respect the meanings and timing of those entities.

If the holder operates its own certification authority, the base registration switch may require no key or entity change. The procedure should verify that the provider transition does not interrupt the allocation relationship on which certificates depend. If the old provider hosts RPKI, the holder must choose continued hosting for a bounded period, transfer to another host, or migration to holder-controlled authority under an approved ceremony.

Parallel run may prepare keys, repositories and intended ROAs, but it must not publish contradictory current authorization merely to test readiness. Cutover sequencing should consider certificate issuance, revocation, repository availability, manifests and relying-party observation. A simplistic instant revocation can create avoidable invalid states.

Proof should observe the resulting entities through independent relying-party views over an appropriate period. It should compare intended prefix and origin authorization, not merely confirm that a repository URL responds. If observation fails, the response follows the RPKI plan; it does not let the old registrar reclaim the whole registration by assertion.

Public-sector portfolios need partitioning and continuity windows

Public bodies often hold resources that support hospitals, schools, emergency communications, tax systems, transport, elections or municipal services. They may also face procurement deadlines that require changing providers. Treating continuity as a reason to prohibit exit would entrench weak suppliers. Treating the portfolio as an ordinary small switch could expose essential services.

The seven-step procedure supports a middle course. The holder inventories services and assigns resource groups by consequence. Low-risk blocks can move first. Shared dependencies are identified. A rehearsal tests export, notices, recovery and observation. High-impact groups receive a scheduled window, additional witnesses and pre-approved restoration actions.

Partitioning should follow operational boundaries, not political convenience. One malformed legacy record should not hold thousands of unrelated resources indefinitely. At the same time, a common RPKI or reverse-DNS dependency may justify moving a coherent group together. The readiness statement explains the choice.

Public accountability also requires records that survive contractor change. Authority contacts, transition receipts and dependency plans belong to the public body or its accountable custodian, not solely to an outgoing supplier's support account. Procurement terms should require cooperation with the common portability procedure from the first day of service. Exit is cheaper and safer when evidence and credentials were designed to move.

Large portfolio switches should be serializable, not monolithic

A provider failure or major procurement can require thousands of resources to move. One enormous commit creates correlated risk. Thousands of unrelated manual transactions create delay and inconsistent decisions. The answer is a declared batch with resource-level authority and partitioned commits.

The request contains a manifest of resources and groups them by holder, dependency and cutover window. Verification can reuse common corporate authority while checking every resource against current state. Notice identifies the full scope and permits objections to specific resources. Clean groups enter parallel preparation while contested items are isolated.

Each cutover group commits against a common batch reference and its own version set. A failure stops that group, not completed groups or unrelated pending groups. Proof reports both aggregate progress and resource-level receipts. This allows an auditor to account for the entire portfolio without pretending that every item changed in one indivisible instant.

Rate controls should protect shared services, but they should be published and capacity-tested. An incumbent should not be able to delay a competitor by claiming that export of normal portfolio data is extraordinary. The Society should maintain tested bulk-transition capacity for provider insolvency. Portability that works only one resource at a time is not continuity planning.

Security depends on independent channels and least authority

Provider switching is attractive to attackers because a successful move can change recovery, public records and hosted security services. The procedure should assume that one account, mailbox or representative may be compromised. High-impact requests require confirmation through an independently maintained holder channel and, where appropriate, two authorized people.

Credentials should be resource-specific, short-lived and bound to the gaining provider and current version. A general account password or reusable export code is too broad. Failed attempts, unusual portfolio scope, new devices and abrupt contact changes can trigger enhanced review, but risk scoring should not become an unexplained denial.

Every role receives least authority. The gaining provider can prepare but not commit. The losing provider can entity on evidence but not approve its competitor. The coordination function can commit the provider field but cannot silently change the holder. Dependency operators can perform their selected transition and no more. Reviewers can order remedies through recorded acts rather than editing history invisibly.

Emergency paths need equal discipline. A claim of compromise may place a short hold and alert protected contacts. Extending the hold requires reasons and review. Emergency restoration after an unauthorized switch is a new ordered event with preserved evidence. Speed is compatible with accountability when powers are narrow, time-limited and observable.

Failure cases test whether the seven steps are real

The old provider is silent. Verification and notice delivery succeed, the objection period expires and parallel readiness is complete. The switch proceeds. Silence is recorded and may affect the provider's performance score, but it does not create a veto.

The holder changes a director during notice. The control claim reports a material authority change. The affected authorization returns to verification. Prepared technical data remains, but the cutover cannot use stale authority. Unaffected resources under a separately authorized public body can continue if the request was partitioned.

A fee dispute emerges. The old provider identifies an unpaid support invoice. Unless a specific lawful stay applies, the base registration switch continues. The debt remains enforceable through ordinary contract remedies. Hosted optional services may end according to disclosed terms, with continuity duties applied as agreed.

One RPKI observation fails. The registration commit succeeds, but independent relying-party views do not show the intended authorization within the expected window. The RPKI contingency action begins. The event is marked incomplete until proof arrives. The old provider cannot issue contradictory entities merely because its former service appeared faster.

A switch was unauthorized. A protected contact presents strong evidence after cutover. High-consequence new changes are held. The reviewer examines request authentication, notices and state events. If unauthorized, restoration occurs through a new commit and all current providers receive notice. History remains intact so the failure can be understood and compensated.

The gaining provider fails mid-transition. Before cutover, the old provider remains current and preparation expires safely. After cutover, continuity provisions appoint a qualified successor or temporary custodian through the same ordered model. The failed provider cannot trap the holder because export and proof were common requirements.

Time limits should reflect risk without rewarding delay

Every step needs a clock. Request receipt should be immediate. Routine verification should have a short published target, with enhanced review explaining what additional evidence is needed. Notice periods should vary by risk class but have fixed outer bounds. Parallel preparation should use a scheduled window. Cutover and receipt issuance should be measured in minutes, while distributed proof may take longer.

Stop-the-clock rules must be narrow. Waiting for holder evidence can pause the relevant verification clock. A provider's staffing shortage cannot. A valid court stay pauses the affected resources. A vague “security concern” cannot pause an entire portfolio indefinitely. Every pause has an owner, reason, start, review time and expiry.

Performance reporting should separate provider-caused, holder-caused, coordination-caused and external delay. Median time alone can hide long tails, so the Society should publish percentiles and aged cases. Measures should include withdrawn requests, expired authorizations, objection rates, objections upheld, failed cutovers, dependency incidents and successful reviews.

Automatic remedies can support discipline. A provider that misses export or notice duties may owe service credits and face qualification review. The holder should not need a costly proceeding to recover a small defined amount. High-impact harm, deliberate obstruction and unauthorized authority changes require separate remedies beyond routine credits.

Evidence preservation should outlast provider relationships

The holder may challenge a switch after the commercial relationship ends. The gaining and losing providers may blame each other. A dependency failure may become visible only after distributed systems update. Evidence must therefore survive long enough for meaningful review.

The common record retains state versions, signed decisions, delivery evidence, comparison results, receipts and dispute events. Providers retain protected authentication and operational evidence for a defined period, with integrity checks and access logs. The holder receives portable copies of its own receipts and relevant declarations.

Retention does not justify keeping everything. Identity images, recovery secrets and raw diagnostic data should be minimized and deleted when their specific purpose ends, subject to active holds. A signed verification result and reasoned decision can often outlast the sensitive source material. Public event history should disclose institutional acts without exposing private authentication details.

If a provider disappears, its required evidence should remain available through escrow, replicated custody or a successor arrangement established during qualification. Continuity cannot depend on an insolvent company voluntarily answering. The evidence mechanism itself should be tested through periodic recovery exercises.

Portability metrics should measure exit, correctness and continuity

A Society could report many completed switches while making them slow, risky or available only to powerful holders. A balanced scorecard should measure successful completion, time by step, authorization failures, valid and invalid objections, state mismatches, dependency incidents, reversal outcomes, cost and holder satisfaction.

Exit concentration is especially revealing. How many holders remain with a provider because hosted RPKI, private evidence or recovery channels cannot move? How many attempted switches abandon during verification? Are small and non-English-speaking holders more likely to fail? Do public bodies face longer unexplained holds? These measures show whether formal rights are usable.

Correctness measures include unauthorized switches, duplicate-current-state attempts, stale-version rejection, missing resources, altered holder fields and proof discrepancies. Continuity measures include RDAP discovery, reverse-DNS errors, RPKI observation and time to restore. Dispute measures include isolation scope, decision time and percentage of outcomes changed on review.

Provider comparisons should be public enough to discipline performance without revealing holder security details. Independent sampling should replay completed transitions from evidence. Disaster exercises should move a synthetic or consented portfolio away from a failed provider. A portability regime that is never tested under incumbent failure is a promise about ideal conditions, not resilience.

Adoption should prove the sequence before demanding scale

The Society should first publish the invariant, roles, state vocabulary, objection grounds, evidence duties, dependency options, clocks and remedies. Providers then implement a common transition record and demonstrate version-bound commits in a test environment. Independent reviewers rehearse unauthorized-switch and provider-failure cases.

Live adoption can begin with consenting holders whose portfolios have limited dependencies. Early cases should include direct operation, hosted reverse DNS, hosted RPKI, a corporate group and a public-sector service. Each case should be replayed after completion. Findings should change the common procedure before scale expands.

Qualification must include exit readiness. A provider proves that it can export holder records, preserve evidence, accept incoming claims, retire authority and continue bounded services after notice. Pricing must disclose transition charges. Optional services should have separate portability terms so they cannot silently lock the base registration.

Bulk capacity and provider-failure succession follow before portability is treated as mature. The Society should be able to move a large portfolio without improvising authority. It should also prove that the common coordination function can be replaced or recovered. Retail choice beneath an irreplaceable coordinator is only partial portability.

Seven steps create a right that can be tested

Request gives the holder an executable start. Verification establishes authority and scope. Notice gives the incumbent and protected contacts a bounded chance to identify error. Parallel run creates continuity without dual authority. Cutover changes one current provider in one ordered event. Proof makes the result independently visible. Dispute isolation contains error without freezing the whole market or creating rival truths.

No step can carry the design alone. Strong verification without a cutover rule produces delay. Fast cutover without notice invites theft. Parallel preparation without authority separation creates duplication. Proof without protected evidence becomes ceremony. Review without isolation turns every conflict into system-wide paralysis.

The sequence also disciplines analogies. Domain transfers show role separation. Mobile switching shows a customer-controlled start and measurable time. Current-account switching shows selected timing, continuity support and responsibility for execution. Number registration remains distinct because globally unique resources interact with RDAP, reverse DNS, RPKI and autonomous routing decisions.

Portability becomes institutionally real when a holder can point to the current state, choose a qualified provider, follow a known sequence and receive proof that authority changed without the resource or holder changing. Seven replayable steps transform exit from a political promise into a service whose security, fairness and continuity can be measured.

Sources and analytical limits

RFC 7020 supports the uniqueness and registration boundaries. RFC 9083 supports the RDAP discussion. RFC 6480 and RFC 9582 support the distinctions among resource certificates, signed routing entities, repositories and route-origin authorization. These technical sources do not prescribe the proposed provider-switching institution.

Comparisons draw on ICANN's published Transfer Policy, Ofcom's mobile-switching guidance and United Kingdom public materials describing the Current Account Switch Service. Each comparison is bounded. Domain names, telephone numbers, bank accounts, IP address space and autonomous system numbers have different law, operators and consequences.

The seven-step sequence, state vocabulary, objection grounds, dependency options, clocks, receipts, isolation rules and adoption order are governance recommendations. Exact time limits and remedies require testing across regions, provider sizes, holder types and applicable law. The high-confidence conclusion is about institutional form: portable registration needs a version-bound, evidenced and independently reviewable sequence that preserves one current authority while making provider exit practical.