Summary
- ICANN's Transfer Policy, effective in its original inter-registrar form since 2004, gives holders of generic top-level domains a common route for changing accredited registrars. The gaining registrar validates the request, the registry verifies the authorization credential, the losing registrar has specified duties and denial grounds, and silence ordinarily leads to approval after five calendar days.
- Portability works because the domain, holder, registrar, registry operator and policy authority are separate roles. An inter-registrar transfer changes the sponsor recorded by the registry; it does not duplicate the domain, change the registered holder or require the holder to move hosting, mail or DNS service.
- Locks show the tension between security and exit. Holder-controlled transfer prohibition can prevent theft, but automatic or obscure restrictions can also trap legitimate customers. ICANN's June 2026 adoption of 47 transfer-review recommendations, pending implementation, reflects continuing efforts to rebalance authentication, notification, reversibility and friction.
- Registrar competition does not create registry competition for the same name. The operator of the top-level domain remains the authoritative wholesale layer, and ICANN's agreements and consensus policies continue to define the common frame. Portability therefore disciplines one intermediary without dissolving upstream authority.
- NRS should advocate adaptation of the enforceable mechanics by recognised registries and authorised providers: holder-preserving provider change, recipient leadership, narrow objections, deadlines, one current provider pointer, retained evidence, independent complaints, emergency reversal and continuity after provider failure.
- NRS must also press the responsible institutions to answer the unfinished questions: who operates and can replace the common authority, which policy follows a resource, how providers qualify, how liability follows control, and how a holder can challenge a captured coordinator without fragmenting uniqueness.
The 2004 settlement made provider exit ordinary
The inter-registrar transfer policy took effect on 12 November 2004. Its purpose was not to make registrars interchangeable or to abolish the registry. It was to give a registered name holder a straightforward route from one accredited registrar to another while preserving a coordinated registration.
That narrow objective changed market power. Before a reliable transfer right, a registrar could retain a customer through friction even when another provider offered better support, pricing, security or administration. The holder's dependence on the domain amplified that friction. A business might be willing to change an ordinary supplier, but not if departure risked its public name, email continuity or the destination printed on products and contracts.
The policy converted exit from bilateral persuasion into a common obligation. A holder approaches the desired registrar. That gaining registrar obtains and validates the necessary authority. The registry receives a transfer command and records the sponsor change. The registrar of record can entity on defined grounds, but it does not possess a general discretion to decide whether the customer should leave.
This is the first NRS lesson. A right becomes credible when its exercise does not depend on the incumbent agreeing with its purpose. The losing institution can authenticate, identify a real conflict and preserve evidence. It cannot make customer loyalty a condition of continuity.
Portability therefore rearranges bargaining before it is ever used. The possibility of exit gives the holder leverage over service, price and responsiveness. A provider must earn continuation rather than treat the identifier's importance as a captivity mechanism.
The architecture separates five roles
Domain governance is often described as though a registrar “has” the domain. The legal and technical structure is more layered. ICANN contracts with accredited registrars and with generic top-level domain registry operators. Registry operators enter registry-registrar agreements that allow registrars to offer registrations under the relevant top-level domain. Registrars or their resellers contract with registered name holders.
Five roles can therefore be distinguished. The registered name holder possesses the customer relationship and authority recognized by the registration agreement. The registrar provides retail registration service and sponsors the name at the registry. The registry operator maintains authoritative registration state for the top-level domain. ICANN supplies accreditation, contracts and common policies for the generic domain space. The DNS operators serving authoritative nameservers may be the registrar, the holder or a completely separate provider.
Portability changes one of these roles. It replaces the sponsoring registrar. The registry operator does not change. ICANN does not change. The holder does not change in an ordinary inter-registrar transfer. The nameserver operator does not have to change.
That separation is the model's intellectual achievement. It prevents commercial service, authoritative state, identity, policy and live technical operation from becoming one indivisible relationship.
Number governance needs an equally explicit map. The resource holder, registration-service provider, authoritative coordination layer, policy authority and routing operator are not the same thing. A provider switch should alter only the recognized service association. It should not sell the resource, change the holder, announce a route or rewrite the policy history.
The registry prevents portability from becoming duplication
A domain transfer does not create two current domains. It changes the registrar sponsorship attached to one registry entry. The gaining registrar sends a transfer command. The registry checks the authorization information, notifies both registrars and maintains the pending or completed state. The losing registrar's previous sponsorship becomes historical when the new sponsorship takes effect.
This is why service competition does not undermine uniqueness. Registrars do not each maintain an equally authoritative version of the same generic top-level domain. They transact through a common wholesale record. A registrar may keep customer records and evidence, but those records do not override the registry's current sponsorship state.
The same design principle can answer the strongest technical objection to number-registry portability. A prefix or ASN would not be copied into competing authoritative worlds. A common coordination layer would record one holder, one resource set and one current qualified registration-service provider. A provider change would be serialized against the current version. After activation, the former provider could retain evidence but could not issue a rival current state.
Uniqueness requires a common answer. It does not require one permanent customer-facing institution.
The difficult issue lies one level higher. Whoever controls the common answer can constrain every provider. Domain registrars are portable because the registry is not. For the model NRS advocates, creation of a shared anchor by recognised institutions is not the end of institutional design. It is the point at which authority must become narrow, reviewable and replaceable.
Holder continuity is the constitutional fact
The most important field in a routine registrar transfer is the one that does not change: the registered name holder. That continuity distinguishes provider substitution from a change of control over the domain.
ICANN's current policy treats inter-registrar transfer and change of registrant as separate matters, even though the rules interact. A change to registrant data can trigger additional confirmation and, under the currently published policy, a 60-day inter-registrar restriction unless an available opt-out was exercised in advance. The complexity exists because changing the administrator and changing the recognized holder create different risks.
Number portability must preserve the same distinction. A network moving registration service from one qualified provider to another is not transferring its prefix to a buyer. The holder's identity, allocation history and applicable conditions continue. A merger, acquisition or sale that changes the holder requires a separate authority determination. Combining the two would let a provider switch conceal a disposition or let a disputed disposition block every ordinary service exit.
A portable number record should therefore display the before-and-after state in human terms. The resource set is unchanged. The verified holder is unchanged. The applicable allocation and transfer history is unchanged. The provider of record changes at a defined time. Any other change must be separately identified and authorized.
Continuity is not merely a convenient assumption. It is the basis on which a fast provider switch can be safer than a holder transfer. The institution validates a narrower proposition and leaves the durable rights question untouched.
The gaining registrar turns choice into a transaction
The holder normally starts by contacting the registrar it wants to join. The gaining registrar is responsible for validating the transfer request and represents to the registry that required authorization has been obtained. This allocation of responsibility aligns commercial incentive with completion.
If the losing registrar controlled initiation, the customer would be required to ask the institution being dismissed to organize its own replacement. Delay could be presented as caution, retention activity could intrude on authentication, and the holder would have to coordinate rivals. Gaining-provider leadership avoids that structural conflict.
The losing registrar still matters. It notifies the holder, checks defined risks, preserves records and can deny on specified grounds. The point is not to exclude the incumbent. It is to prevent the incumbent from owning the doorway.
NRS should advocate that allocation. The receiving number-registration provider should accept the request, verify organizational authority, identify the resource set, obtain a fresh view of current state and submit one signed provider-change instruction. The current provider should confirm or identify a bounded defect. The common coordinator should test eligibility and order the state change.
This arrangement distributes distrust. The recipient cannot appropriate a resource merely because it wants the customer. The incumbent cannot retain the customer merely because it controls existing records. The coordinator does not invent holder consent. Each entity supplies a different fact, and completion depends on their consistency under a published rule.
An authorization code is useful because it is narrow
The current domain regime uses an AuthInfo code, while the adopted 2026 recommendations use the clearer term Transfer Authorization Code for future implementation. The credential is created by the registrar of record, associated with a domain and presented through the gaining registrar. The registry verifies it as part of accepting the transfer request.
Its value lies in scope. A transfer credential is not a general login, proof of beneficial ownership or permanent power over every domain function. It authorizes an eligible sponsor change. A court order, an applicable dispute lock or another valid restriction can still make the domain ineligible even when the code is correct.
The February 2025 review recommendations sharpen this design. They call for codes with at least 128 bits of entropy under RFC 9154, a maximum 120-hour issuance period, and a registry-enforced validity period of 336 hours. ICANN's Board adopted the full package on 7 June 2026 and directed implementation, but adoption did not itself replace the current published requirements.
A number-provider switch should likewise use a single-purpose credential bound to the holder, resource set, recipient and current record version. It should expire. It should not authorize a holder transfer, new route-origin authorization, contact replacement or deletion of history. Multiple approval may be appropriate for a large organization, but the resulting credential should still express one narrow act.
Narrow credentials reduce both theft and institutional overreach. They allow strong authentication without turning the provider into custodian of an all-purpose master key.
Deadlines convert silence from power into outcome
Under the current Transfer Policy, the registrar of record must send its confirmation notice promptly and no later than 24 hours after receiving the registry notice. Failure to respond within five calendar days results in default approval. Where the holder cannot directly manage the transfer lock or authorization code, the registrar must provide the needed access within five calendar days of the request.
These periods are not proof that every transfer is effortless. They are an allocation of power. Without a deadline, the incumbent can delay while describing the request as pending. With a deadline, silence has a defined consequence and the holder can identify non-performance.
The default matters as much as the number of days. An obligation to “respond” would still allow silence to veto departure if no one could complete without it. Default approval prevents non-participation from becoming an indefinite hold, while specified dispute and security conditions preserve justified intervention.
The portable-service model NRS advocates needs several clocks, administered by responsible providers: acknowledgment by the recipient, issuance of the transfer credential, delivery of the current state export, statement of any objection, readiness checks for dependent services, activation and emergency review. More complex resource portfolios may require longer windows than a domain sponsorship change. The duration should be tied to named work, not institutional status.
Every pause should show who requested it, which resource subset it reaches, what evidence supports it and when it expires or receives review. Portability fails when the incumbent controls both the delay and the explanation.
Denial grounds make cooperation enforceable
The current domain policy identifies circumstances in which a registrar may deny and others in which it must deny. Evidence of fraud, a reasonable identity dispute and certain payment defaults can support denial. Pending domain disputes, a competent court order and specified transfer-related proceedings can require it. The registrar must give the holder and potential gaining registrar the reason.
The same policy states what is limited public evidence. Non-payment for a future registration period, holder silence by itself, an ordinary registrar lock without a reasonable opportunity to unlock, and general payment defaults between a registrar and its business partners do not create an unrestricted right to block transfer. Payment collection has mechanisms separate from the transfer right.
This is institutional maturity in compact form. The incumbent does not receive a vague power to act “for security” or “for compliance.” It receives a list tied to evidence and consequence.
For numbers, valid objections might include a proven authority defect, a directly applicable court restraint, a current fraud investigation supported by specified indicators, an overlapping holder-change instruction, or a technical readiness failure that would cause an identified security discontinuity. A political disagreement, criticism of the provider, an unrelated invoice or a request for documents outside the published standard should not suffice.
The objection must also be divisible. A restraint affecting one prefix should not freeze an unrelated portfolio. A disputed contact field should not erase the last verified resource record. Precision prevents exceptional powers from swallowing ordinary exit.
Locks protect holders only when holders can control them
Domain locks illustrate the central tension in portability. The clientTransferProhibited status can stop an unauthorized move. A holder who fears theft can request it, and a registrar can provide self-service controls. Used well, the lock expresses the holder's own security preference.
The same mechanism can become captivity. If the holder cannot see the lock, cannot remove it through a reasonable method or discovers an automatic restriction only after preparing to leave, security authority has shifted to the incumbent. The current policy therefore requires removal within five calendar days when self-service is unavailable and bars more restrictive methods for obtaining the code or unlocking than those used for changing other holder information.
The post-change 60-day restriction shows how difficult the balance remains. The 2025 working group documented confusion and inconsistent treatment, then recommended removing that restriction from the future change-of-registrant-data policy while adding a standardized 720-hour restriction after an inter-registrar transfer. The Board adopted the recommendations in June 2026, with implementation still to follow.
The lesson for NRS is not to choose one universal lock period by analogy. It is to assign the lock. Holder-requested protection, emergency integrity holds and legal restraints are different instruments. Each needs its own trigger, visibility, duration, removal authority and appeal.
A lock that the incumbent can impose indefinitely is not a security feature. It is an ownership claim expressed through administration.
Notifications give continuity a human witness
Transfers happen in systems, but the holder must be able to recognize them. The current regime requires notices around the pending request, and the adopted recommendations add a losing-registrar notification of completion within 24 hours using contact information held at the time of the transfer request.
That last detail matters. If an attacker changes contact data during an account compromise, notice sent only to the newly substituted contact can confirm theft to the thief. Preserving the pre-transfer notification destination creates an independent witness to the change.
Number-provider portability should notify multiple pre-registered roles: an organizational authority contact, a network operations contact and a security or recovery contact. The content should identify the resource set, old and new providers, requested activation, any related service changes and the route for urgent challenge. It should not reveal private evidence to recipients who do not need it.
Notification cannot substitute for authorization. An email ignored during a holiday should not automatically prove consent to a high-consequence change. Its role is detection, transparency and recovery. The actual instruction should be authenticated through a stronger mechanism.
Completion also needs a durable receipt. The holder and both providers should receive the record version, effective time, coordinator signature and the unchanged holder identity. A human-readable notice and machine-verifiable event should describe the same transition.
Transfer disputes reveal the remedy gap
ICANN maintains a Transfer Dispute Resolution Policy for disputes between registrars about inter-registrar transfers. A registrar can bring a case through the relevant registry operator or an independent dispute provider. Holders can also use ICANN's transfer-complaint channel when an accredited registrar does not meet its obligations.
These remedies are important but reveal a boundary. The formal transfer-dispute procedure is primarily registrar-to-registrar. The holder commonly depends on a registrar complaint, contractual rights or other legal avenues rather than possessing one universal adjudication forum for every transfer loss.
Portability is therefore not complete merely because a command can be sent. It requires an accessible remedy when the command is blocked, forged or mishandled. The remedy must reach the actor that controls the decisive state.
NRS should advocate that recognised provider agreements give a holder a direct right to challenge an unsupported denial, stale lock, missed deadline or unauthorized completion. An independent reviewer should be able to order release of a credential, expiry of an invalid hold, restoration of the last verified provider state or a correcting transition. Wider ownership and contractual damages can remain for courts or arbitration.
The reviewer needs evidence from recipient, incumbent and coordinator. If one actor controls the logs, selects the reviewer and executes the remedy at discretion, review is ceremonial. Remedy design must follow the location of power.
Registrar failure proves that ordinary consent is not enough
Normal transfer assumes a functioning registrar. Domain governance also prepares for a provider that loses accreditation or can no longer serve customers. Accredited registrars regularly deposit specified generic-domain registration data with an approved escrow provider. ICANN can use approved bulk-transfer arrangements to move registrations when continuity requires a successor.
The holder may not have chosen the emergency recipient in the first moment. That exception is justified by stabilization, not by permanent customer assignment. Once service is secure, ordinary choice should return.
This tail case is critical for number registration. A portability right that depends on the losing provider issuing a credential is weakest precisely when exit is most necessary. The responsible registry framework needs independently recoverable current state of the kind NRS advocates, tested export formats, replicated authorization evidence and an emergency successor rule. Recovery cannot depend on a proprietary archive that only the failed provider knows how to interpret.
Escrow alone is limited public evidence. The restore must be rehearsed. The restored state must distinguish current holder, historical contacts, active disputes, pending changes and dependent technical services. Credentials that should not survive compromise must be replaced, while evidence needed to validate the holder must remain available.
Provider failure turns portability from competition policy into continuity engineering. The domain regime recognizes that distinction. Number governance should design for it before the first provider becomes indispensable.
DNS continuity shows that administration and operation can diverge
A registrar transfer does not necessarily move authoritative DNS hosting. If the nameserver delegation and related configuration remain intact, the domain can continue resolving while the sponsoring registrar changes. The registrar may also sell hosting, mail or DNS service, but those commercial bundles do not erase the functional separation.
This is a powerful analogy for number resources. A network can change the institution that maintains recognized registration data without changing upstream connectivity or BGP announcements. Registry service is not transit. A prefix does not have to move geographically. An ASN does not become a different autonomous system.
The analogy becomes more complex around dependent security functions. Domain DNSSEC information often passes through registrar and registry interfaces. Number-resource registration can connect to reverse DNS and RPKI. A provider change that preserves the main record but accidentally removes security material is not successful continuity.
NRS should advocate that responsible institutions separate stable functions from cutover functions. Holder identity and allocation history remain. The provider pointer changes. RDAP discovery updates at activation. Reverse-DNS and RPKI changes follow explicit plans with pre-validation and recovery. Live routes remain under operator control.
The domain example proves administrative separability, not effortless migration. Its usefulness is greatest when the dependent functions are named rather than hidden behind the word “transfer.”
Portability created registrar competition, not a policy marketplace
Registrars can compete on price, support, interface, security controls, language, portfolio tools and complementary services. They do not normally compete by offering the holder a different global rule for whether a generic domain transfer is valid. Common policy is part of what allows the registry to accept instructions from many registrars without creating incompatible states.
That constraint is productive. If each registrar could redefine ownership, ignore dispute locks or invent its own authorization standard, portability would become forum shopping. The holder's ability to leave a provider depends on the receiving provider being bound by enough of the same institutional frame.
Number portability also needs a baseline that follows the resource: uniqueness, recognized holder continuity, minimum evidence, security, record retention, lawful restraints and review. Providers can compete on service without selling exemption from these duties.
But common policy creates a legitimacy question. Who writes it? Whose interests count? How can a holder challenge a rule that every provider must enforce? The registrar market does not answer those questions; it relocates them above the retail layer.
NRS should not advertise provider choice as complete autonomy if one central body can change the governing conditions without proportionate representation, reasoned decisions or appeal. Exit from a registrar is meaningful. It is not exit from the common authority.
The registry layer remains deliberately unportable
A .com holder can move between accredited registrars while the .com registry remains the authoritative wholesale operator. Moving the same label to another top-level domain would produce a different domain name. The holder therefore cannot preserve the complete identifier while choosing a different registry operator.
Registry operation can change through contractual succession or emergency continuity arrangements, but that is not an ordinary holder-directed port. It is a change in the infrastructure serving an entire top-level domain. The scale and constituency are different.
This is the unfinished lesson. Registrar portability solves captivity at the retail registration layer. It does not create competition among authoritative registries for the same identifier. The registry's monopoly is bounded by contract, technical standards, oversight and the possibility of operator replacement, not by each holder selecting a wholesale ledger.
A number system could adopt the same architecture: many service providers around one common authoritative coordinator. That may be the safest initial model. It also creates the same concentration risk. If the coordinator sets admission, controls every provider change and cannot itself be replaced, retail choice may disguise a constitutional monopoly.
NRS must state plainly that it is an advocacy and member-representation organisation, not a provider, coordinator, accreditor or reviewer. Assuming any combination of those operational roles would recreate the dependency portability is supposed to reduce.
Policy authority is the layer portability does not dissolve
ICANN's agreements require accredited registrars and generic registry operators to follow applicable consensus policies. The transfer rules developed through the Generic Names Supporting Organization and approved by the Board illustrate how common obligations can evolve across the market.
The 2021-2025 review took years, produced 47 recommendations, received unanimous GNSO Council approval in March 2025 and Board adoption in June 2026. That history demonstrates deliberation and also latency. A holder facing a lock today cannot personally accelerate system-wide policy reform.
The distinction between individual exit and collective rule change is essential. Portability lets the holder leave one provider under the current rules. Governance lets affected communities change the rules that bind all providers. One cannot substitute for the other.
NRS should advocate both paths and ask responsible institutions to build them. A holder should not need to win a policy debate to complete an ordinary provider switch. At the same time, recurring denial patterns, security incidents and disproportionate fees should feed a transparent policy-review mechanism. Providers, holders, network operators and affected technical communities need standing to propose changes and see reasoned outcomes.
Provider competition disciplines service. It does not automatically legitimate the constitution above the providers. The domain experience is strongest when it prevents reformers from making that category error.
Common authority needs limits stronger than benevolence
The registry has a narrow technical reason to exist: the top-level domain needs one authoritative registration state. ICANN has a coordination reason to accredit registrars and establish common obligations. Neither reason proves that every decision made at those layers is legitimate.
Institutional legitimacy requires scope, evidence, review and succession. The common coordinator should publish what it decides and what it does not decide. Its operational service should be independently audited. Admission and discipline of providers should follow criteria rather than political preference. Fees should correspond to necessary functions. Emergency power should expire unless reviewed.
For the model NRS advocates, the strongest authorised design would make the shared state verifiable without making its operator sovereign. Signed events, public technical specifications, independent replicas and exportable history can allow continuity if the operator fails. Governance should separate operation of the ledger from provider qualification and dispute review. No provider should control a majority of the body judging competitors, and NRS should not sit as the accreditor or adjudicator.
The coordinator must also be replaceable. A tested succession plan, multiple custodians and periodic recovery exercises are more convincing than a promise of permanent neutrality. Institutions change ownership, leadership and incentives. Architecture should assume that fact.
Portability that ends at an immortal coordinator has moved lock-in, not removed it.
Number resources require a stricter separation from routing
The domain analogy becomes dangerous if a registrar is treated as equivalent to a route operator. DNS resolution follows delegations within the domain-name hierarchy. Internet routing emerges from BGP announcements and policy decisions among autonomous networks. The number registry records allocations and registration information; it does not choose every route.
RFC 7020 makes the boundary clear: how addresses are announced and advertised is outside the scope of the Internet Numbers Registry System. RFC 6480 adds another distinction: RPKI resource certificates attest to allocations and authorization, not to descriptive identity in the ordinary public-key sense.
A number-provider port should therefore leave routing untouched unless the holder separately changes it. The receiving registration provider does not become the origin AS, transit carrier or network operator. It should not require the holder to demonstrate a route change merely to prove that service moved.
RPKI needs careful continuity because authorization entities rely on the resource-certificate hierarchy. That dependence makes provider replacement harder than a simple registrar pointer change. It does not justify permanent institutional captivity. It requires staged issuance, overlap rules that do not create contradictory authority, relying-party testing and a restoration path.
The domain comparator supplies the constitutional separation. Number-specific engineering must supply the safe transition.
A minimum transfer advocated by NRS should be inspectable
The first authorised service-port transaction under a model NRS advocates should be smaller than the political theory around it. It should identify the current holder, resource set, incumbent provider, receiving provider, record version and requested effective time. It should list active restraints and dependent services without importing unrelated membership disputes.
The holder authorizes through a credential bound to that exact instruction. The receiving provider verifies organizational authority and technical readiness. The incumbent supplies a signed current-state export and one of a limited set of responses. The coordinator checks that no conflicting instruction has already consumed the current version.
If eligible, the coordinator schedules activation. RDAP discovery and the provider pointer change together. Reverse-DNS and RPKI steps use declared service-specific plans. The holder and providers receive completion notices and one signed receipt. The old provider loses current write authority but retains protected evidence for audit and dispute.
If activation fails, the last verified state remains or is restored. A recovery event explains the result. A correction does not erase the attempted transition from history.
Every exception should be visible in the transaction: authority defect, legal restraint, active fraud concern, resource overlap, state mismatch or dependent-service readiness failure. A free-text institutional veto should not exist.
The domain transfer system became useful by turning a broad right into roles, commands, clocks and receipts. NRS advocacy should begin with the same discipline.
Metrics should distinguish choice from successful exit
Counting qualified providers would not prove portability. A market can contain many providers while incumbents make departure slow, opaque or dangerous. Counting transfer requests alone also misses abandoned attempts and customers who never begin because they expect failure.
NRS should campaign for responsible providers to publish completion rates, median and tail times, credential-issuance delays, objection reasons, expired holds, holder cancellations, unauthorised attempts, reversals and continuity incidents, then compare the sourced results. Results should be attributable to provider class without exposing sensitive holder evidence.
It should also measure concentration at each layer. How many holders use each service provider? Who operates the common coordinator? How dependent is the system on one credential issuer, data custodian or review body? How often are provider applications approved, conditioned or rejected? Retail plurality can coexist with upstream concentration.
Domain governance offers another useful measure: policy responsiveness. Transfer rules remained under review for years because security, privacy changes and operational experience altered the balance. A number regime should disclose how evidence becomes policy change, who can propose it and how long adopted reforms take to reach operation.
Performance data connects individual rights to institutional legitimacy. Without it, a provider can claim every delay is exceptional and a coordinator can claim neutrality without showing equal treatment.
Liability must follow the actor that controls the failure
Portability reallocates control, so it must also allocate responsibility. The gaining provider authenticates the holder and should answer for careless acceptance. The incumbent controls credentials and current evidence and should answer for unsupported delay or release. The coordinator controls final ordering and should answer for conflicting state or completion against an active valid restraint.
No single actor should bear every consequence. A stolen holder credential is different from a registry accepting two current sponsors. A missed notification is different from an unauthorized RPKI change. Remedies should track the failed duty.
The immediate remedies are operational: stop, restore, correct, notify and preserve evidence. Financial remedies should cover defined direct costs caused by proven failure, while wider damages remain available under applicable contracts and law. Repeated misconduct can trigger supervision, suspension or loss of qualification.
This is where domain portability remains less complete from the holder's perspective. Technical transfer rules and compliance complaints do not create one comprehensive compensation system for every consequential loss. NRS should not copy that gap merely because the comparator has it.
Authority without liability invites caution to be imposed on the customer and risk to be externalized onto the network. A legitimate portability regime makes each controlling actor carry the cost of the failures it can prevent.
The analogy has firm limits
A domain name and an IP prefix are globally coordinated identifiers, but they do different work. Domain names are delegated within the DNS and sold under registration agreements. Addresses and ASNs are distributed through the Internet Numbers Registry System and used in routing. Their policy histories, scarcity conditions, transfer markets and security dependencies differ.
A domain registrar transfer changes sponsorship within one top-level registry. A cross-regional number-provider switch may cross institutional and jurisdictional boundaries that have no direct generic-domain equivalent. A prefix can cover downstream assignments and carry reverse zones, resource certificates and route-origin authorizations. An ASN can be operationally visible in paths regardless of what a registration service says.
The domain model also rests on ICANN's contracts. NRS cannot acquire equivalent legitimacy by adopting familiar terminology. Any portability service needs recognised rules, willing entities, technical interoperability and lawful remedies; NRS advocacy does not supply them. A common database created by one company is not a public authority merely because it records unique identifiers.
Nor does registrar choice prove that registry-level competition is safe or desirable. The domain system chose a common registry per top-level domain. Number governance must decide which functions truly require one current state and which can be distributed.
The comparison should therefore answer possibility, not destiny. Provider portability and uniqueness can coexist. The exact number architecture still has to earn trust.
The unfinished lesson is the most useful one
Domain transfer established a durable principle: the customer-facing intermediary is not the identifier. A holder can change registrar while the name, holder and public function continue. Common authorization, bounded objections, a registry commit, time limits, notifications and failure continuity make that separation practical.
For NRS, this is enough to reject institutional permanence as a technical necessity. An RIR or other registration-service provider can be replaceable while a prefix or ASN remains unique and its holder history remains intact. Routing need not move merely because administration does.
But the domain model also warns against declaring victory at the retail layer. The registry remains authoritative. ICANN's contracts and consensus policies remain common. Holders can choose service within that frame, not choose whether the frame applies. Security locks can protect or entrench. Dispute remedies can exist while remaining difficult for the affected holder. A shared operator can preserve continuity while accumulating power.
The proper NRS advocacy objective is therefore layered portability. First, make the registration-service provider replaceable through an executable holder right. Second, make the common coordinator operationally replaceable through replicated state and tested succession. Third, make policy authority accountable through representation, evidence, reasoned decisions and review. Fourth, preserve routing autonomy and dependent-service continuity without pretending that every function is the same ledger entry.
Portability does not abolish authority. It reveals where authority remains after the customer leaves.
That is the domain transfer regime's unfinished lesson for numbers: solve the lock-in that can be solved, then refuse to hide the monopoly that has merely moved one layer upward.
Evidence and analytical limits
This analysis relies on ICANN's current Transfer Policy, registrant transfer guidance, transfer complaint materials, registrar agreements and policy summary, description of relationships among domain-industry parties, registrar data-escrow requirement, transfer-dispute materials, the February 2025 Transfer Policy Review final report and the Board's 7 June 2026 adoption resolution. RFC 9154 supplies the security basis for future transfer credentials. RFC 7020 and RFC 6480 establish the distinct purposes of Internet number registration, routing operations and resource certification.
The current published Transfer Policy and the adopted recommendations are kept separate. The Board adopted the 47 recommendations and directed implementation in June 2026; this article does not claim that the future 720-hour restrictions, transfer-code terminology or associated notification rules had already replaced the live policy on 15 July 2026.
ICANN materials establish duties and institutional structure. They do not prove that every registrar performs equally well, that every country-code domain follows the same rules or that holders have complete remedies for all losses. The article is limited primarily to generic top-level domains governed by ICANN's transfer regime.
The design advocated by NRS is derived from the comparison. No current universally recognized cross-RIR provider-portability service is inferred. Domain names, IP address blocks and ASNs are not treated as legally or technically identical. The comparison supports role separation, enforceable exit and common-state ordering; number-specific implementation would still require independent security testing, recognized authority, jurisdictional analysis and demonstrated continuity for RDAP, reverse DNS and RPKI.
Sources
- ICANN, Transfer Policy — current gaining-registrar and registrar-of-record duties, authorization, response times, denial grounds, locks, credentials, registry requirements and holder-change rules.
- ICANN, FAQs for Registrants: Transferring Your Domain Name — holder-facing description of the right to change registrars and the restrictions that may apply.
- ICANN, About Locked Domain — holder-controlled unlocking and the transfer-complaint route when a registrar does not provide timely access.
- ICANN, Relationship Between Domain Name Industry Parties — separation among ICANN, registry operators, registrars, resellers and registered name holders.
- ICANN, Registrar Agreements and Policies — accreditation, consensus-policy, registration-agreement and registrar data-escrow obligations.
- ICANN, Domain Name Dispute Resolution Policies — scope and institutional route of the Transfer Dispute Resolution Policy.
- GNSO, Transfer Policy Review Final Report, 4 February 2025 — 47 recommendations on credentials, restrictions, notifications, emergency contact, reversal, disputes and approved bulk transfers.
- ICANN Board, Approved Resolutions of 7 June 2026 — adoption of the 47 recommendations and direction to implement them.
- RFC 9154, Extensible Provisioning Protocol Secure Authorization Information for Transfer — security properties for transfer authorization information.
- RFC 7020, The Internet Numbers Registry System — uniqueness, registration accuracy, registry hierarchy and the boundary between registration and routing.
- RFC 6480, An Infrastructure to Support Secure Internet Routing — the resource-certificate hierarchy and the distinction between allocation authorization and descriptive identity.

