The ROA That Survived a Transfer Too Long: Safe RPKI Handover

Summary

A transfer has at least three clocks: the commercial agreement, the registry's holder change and the RPKI state seen by each relying party. Declaring success on only one clock can leave the recipient's route invalid or the transferor's former origin AS cryptographically authorised.
A ROA authorises an origin AS for stated prefixes and maximum lengths. It is neither a transfer instrument nor a complete statement of operational control, but route-origin validation can make its survival or disappearance immediately consequential for reachability.
RFC 6480 established the correct direction in 2012: make before break. Before revoking an old ROA, another valid ROA should cover the route that is meant to remain reachable, and the intended origin should actually be announcing it.
During a cooperative transfer, the transferor can create a temporary bridge authorisation for the recipient's intended origin AS because the authorised ASN need not belong to the signing holder. The recipient must then create an equivalent ROA under its own new certificate before that bridge is retired.
A safe handover needs a locked event record containing the exact resources, intended origins, maximum lengths, old and new certification paths, effective point, required observations and authority to abort. Registration completion, publication and revocation should be indivisible from the parties' perspective even though global caches cannot update simultaneously.
Overlap is useful only when it is explicit, narrow and expiring. An old authorisation that remains after transfer without a stated bridge purpose creates residual power; a gap between old revocation and new validation can change a route from Valid to Invalid or NotFound depending on what each relying party has fetched.
Multiple validators and observation points should confirm both positive and negative facts: the new payload is visible through the expected trust anchor, the old payload is no longer valid, the live BGP origin matches the authorised state and no unexpected covering authorisation changes the result.
A Number Resource Society can contribute positively by defining a portable handover receipt, minimum evidence, independent observation and accountability rules across providers. It should not claim that one universal waiting period makes every transfer safe; repository timing, hosted or delegated operation and inter-regional coordination differ.

A transfer fails in the interval between institutional clocks

The easiest transfer to describe is instantaneous. One organisation ceases to hold a prefix, another becomes the recognised holder, and the right origin AS appears in routing. The actual event is distributed among institutions and machines that do not share a clock. A contract may become effective at midnight. A registry officer may approve the holder change later. A certification authority may issue a new resource certificate and revoke an old one in a separate publication action. Relying parties fetch those entities on their own schedules. Routers receive validated payloads from local caches and apply local policy.

That sequence creates two opposite hazards. Break before make occurs when the transferor's authorisation is withdrawn before an alternative for the intended route has become valid and visible. If a covering authorisation still exists for another origin, the new announcement may be Invalid. If no covering validated payload remains, the route may instead be NotFound. Operators treat those states differently, so the same transition can preserve reachability in one network and lose it in another.

Make without break is the mirror image. The recipient receives a certificate and publishes the new authorisation, but the transferor's old authorisation remains valid longer than the handover requires. Both origin ASes may then produce routes that pass origin validation. RPKI does not choose between two separately authorised origins merely because the commercial transaction has completed. The old path may survive in some caches after it has disappeared from others, extending disagreement beyond the registry's declared effective time.

The governing question is therefore not whether a transfer form was approved. It is whether authority moved through a controlled sequence with no unexplained gap and no unexplained residue. A registry that records holder identity and a certification authority that changes cryptographic authority are participating in one consequential event. Their controls should be designed accordingly.

A ROA proves less than a transfer and matters more than a footnote

A Route Origin Authorisation is a signed statement that an autonomous system is authorised to originate routes for one or more prefixes, subject to any maximum-length value. Its validity depends on the signed entity, its end-entity certificate, the issuer's certificate chain, manifests, revocation information and the trust anchor accepted by the relying party. The current profile is set out in RFC 9582, building on the RPKI architecture established in 2012.

The statement is deliberately narrow. It does not convey the prefix, settle payment, identify every beneficial interest or prove that the named AS is currently announcing a route. A seller can authorise a buyer's or provider's ASN before a transfer because the origin ASN does not have to be contained in the signing holder's resource certificate. Conversely, a buyer may hold the prefix but use a third-party network as the authorised origin.

Narrowness does not make the entity peripheral. Route-origin validation turns valid ROA payloads into inputs for routing policy. A network rejecting Invalid routes can stop accepting an announcement when the relevant authorisation changes. A stale authorisation can allow an origin that should have lost permission to retain a Valid classification. The entity is not title, but it is an operationally potent statement derived from the institution that recognises the holder.

This distinction should discipline both sides of the transfer market. Buyers should not assume that receiving the registration automatically preserves every routing authorisation. Sellers should not assume that the sale agreement automatically extinguishes an old signed entity everywhere. Registries should not describe automatic certificate updates as the whole of continuity. Validators should not infer transaction legitimacy; they can only assess the certification paths and payloads they receive.

The handover must connect the narrow cryptographic claim to the broader event without asking either to impersonate the other. The transfer instrument supplies authority for the holder change. The registration action changes who may control resource certification. The ROA authorises the intended route. A safe transaction proves that these related acts occurred in the right order.

Valid, Invalid and NotFound are transition outcomes, not moral verdicts

Origin validation compares a BGP announcement with validated payloads. A route is Valid when a payload covers the announced prefix, permits its length and names the observed origin AS. It is Invalid when relevant covering payloads exist but none authorises that combination. It is NotFound when no validated payload covers the announcement. These categories express a comparison, not a judgment about ownership, fraud or business merit.

During transfer, the distinction becomes a diagnostic tool. Suppose the old ROA authorises AS-A and the recipient intends to originate from AS-B. If AS-B begins while validators still hold only the AS-A payload, its route is Invalid. If the old payload has vanished and the AS-B payload has not arrived, the route is NotFound. If both payloads are present, both origins can be Valid. If the recipient continues using AS-A through a common transit arrangement, the route can remain Valid even though holder authority has changed, but the operational continuity should be stated rather than guessed.

No single observation proves the global state. One relying party may have fetched a new RRDP delta. Another may be using a prior valid cache after a repository failure. A third may obtain data by a different transport or reject a publication point after manifest checks. Their software can also differ in how it handles an exceptional repository condition within the bounds left to local policy. A transfer can therefore produce a temporary mosaic of results.

The correct response is not to promise universal simultaneity. It is to define acceptable transition states and measure them. A planned overlap in which AS-A and AS-B are both valid may be acceptable for a short, declared bridge. An unexplained overlap after the transferor's authority should have ended is not. A short NotFound interval may preserve reachability at networks that reject only Invalid routes, but it is still a failure of authorisation continuity. An Invalid interval is more acute, especially where filtering is enforced.

Governance begins by naming those states accurately. It then assigns responsibility for preventing, observing and closing each one.

The 2012 architecture already supplied the governing verb: make before break

RFC 6480 does not treat ROA revocation as a clerical deletion. It warns that revocation may cause relying parties to regard associated advertisements as unauthorised and potentially change forwarding behaviour. It therefore tells resource holders to follow make before break: ensure that another valid ROA exists for the prefix, ensure that the AS named by the alternative is actually originating the intended advertisements, and require relying parties to fetch new entities before acting on revocation.

That sequence remains the sound starting point. Its significance is easy to obscure in modern interfaces where a user clicks a transfer or certificate control and the service updates several entities. Automation can execute the principle, but it does not repeal it. The existence of a web control marked complete says little about when independent validators observed the replacement and the revocation.

Make before break is also more precise than simply leaving the old ROA online for an arbitrary grace period. The thing to be made is a valid alternative corresponding to the route that will actually be announced. A replacement with the wrong origin ASN, an excessively narrow prefix, an unsuitable maximum length or an invalid certification path does not satisfy the condition. Nor does a correct entity that has been generated but not published coherently.

The thing to be broken is the former authority, not merely a filename. Standard revocation involves the end-entity certificate, current revocation information and removal of the obsolete entity. If the resource itself moves from an old resource certificate, the old chain must no longer validate that authority. Manifests need to describe the current publication point accurately. The resulting state must be consumable by relying parties rather than visible only inside the issuing service.

The phrase should thus be read as an institutional rule: establish usable successor authority, observe it independently, then extinguish predecessor authority and observe that extinction. A transfer is unfinished until both halves are evidenced.

Registration change and route change are related events, not the same event

A transfer can preserve the same origin AS. A company may buy an address block but continue using the seller's network temporarily. A group reorganisation may change the registered organisation while the operational network stays constant. A brokered sale may require a new holder but use an established transit provider before the recipient has its own ASN. In each case, registration changes while the route may not.

The reverse can also occur. The intended route can move from AS-A to AS-B before the legal transfer becomes effective, with the existing holder authorising AS-B for a migration period. That is operational delegation, not proof that the resource has already transferred. Treating origin change as holder change would misread what a ROA says.

Safe handover therefore needs two linked plans. The registration plan identifies the transferor, recipient, exact resources, applicable policy, evidence, effective condition and authority to approve or restrain the change. The routing-authority plan identifies each intended prefix and maximum length, the origin before and after, any provider relationship, the entity to be created, and the point at which old authority should end. If no route change is intended, the plan says so and tests continuity of the existing origin under the new holder's certificate.

Linkage matters because one plan can invalidate assumptions in the other. A certificate may change automatically when the registry organisation entity changes. RIPE NCC documentation states that a moved or transferred resource changes the certificate, removes underlying ROAs and requires them to be recreated. A buyer who planned only the registration can therefore discover that a continuing route has lost its validation basis. A routing engineer who prepared a new ROA without knowing the effective registration point may discover that the recipient cannot yet sign for the prefix.

The event record should not collapse these acts into one status label. It should show that registration was authorised, successor route authority was prepared, publication was observed, predecessor authority was retired and the live route matched the intended state.

A cooperative transfer can use a bridge without surrendering finality

The most useful continuity device is a narrowly defined bridge ROA. Before transfer completion, the current holder can authorise the recipient's intended origin AS. That entity is legitimate because a ROA binds a prefix to an origin ASN; the signer need not hold the ASN. The recipient or its network can then begin or prepare the intended announcement while the old certification path still exists.

The bridge solves only the first half. Once the recipient becomes the recognised holder and receives certification authority for the resource, it should publish an equivalent authorisation under its own chain. Independent validators should observe that successor payload. The transferor's bridge and any authorisation for its former origin should then be revoked through the old chain as the resource leaves that certificate.

This creates a controlled interval in which equivalent authorisations may exist under two chains. Equivalence should be tested field by field: address family, prefix, maximum length and origin ASN. A bridge that permits more-specific announcements beyond the recipient's agreed plan grants extra authority. A successor entity that omits a production more-specific can turn that route Invalid even when the aggregate remains Valid.

The bridge also needs an expiry condition outside the entity itself. Its governance record should say that it exists solely for transaction continuity, identify the transfer reference, forbid unrelated changes, and require revocation after successor validation. If the transfer does not complete, the current holder should be able to retire the bridge under a defined abort procedure. If the transfer completes but the old authority cannot be retired, escalation should begin immediately rather than converting a temporary overlap into an indefinite convenience.

Not every transfer is cooperative. A court-directed transfer, insolvency sale or disputed succession may make prior-holder action impossible. In those cases, the registry needs a continuity path that can issue the recipient's new authority as part of the effective holder change and revoke the old chain coherently. The absence of a bridge raises the need for tighter publication readiness and explicit rollback; it does not justify pretending that caches update atomically.

The handover needs a state machine, not a completion email

A credible event can be represented in six states. The first is declared intent. The parties specify the exact resources, current and intended origin patterns, relevant maximum lengths, old and new certification arrangements, contact authorities and the evidence authorising the transfer. The registry returns a unique reference and freezes conflicting certification changes for the affected resources.

The second state is successor preparation. Where cooperation permits, the transferor publishes the bridge authorisation. The recipient prepares its hosted or delegated certification service, repository access and ROA configuration. Automated checks confirm that the intended entity would validate if issued under the expected resource certificate.

The third state is route readiness. Observation confirms that the intended origin is announcing the exact routes expected, or that the existing origin will continue. This does not require prematurely shifting traffic; it requires evidence that the operational plan and proposed authorisations agree. Errors in prefix length and origin ASN should be corrected before the authority change.

The fourth state is effective transfer. The registry changes the recognised holder, the issuing hierarchy updates the resource certificates, and the successor authorisation is published with current manifest and revocation material. For an inter-regional transfer, source and destination actions need a common event reference and agreed release and acceptance conditions even though they occur under different trust anchors.

The fifth state is predecessor retirement. The old resource certificate can no longer validate authority for the transferred resource, relevant end-entity certificates are revoked, obsolete entities are withdrawn and the old manifest describes the new publication state. The transferor's credentials no longer permit new certification actions for the prefix.

The sixth state is observed closure. Independent relying parties see the successor payload, no longer validate the predecessor payloads, and classify the live route as intended. Exceptions are recorded by observation point and cause. Only then should the event be marked cryptographically closed. Commercial completion may have occurred earlier, but the record should preserve the distinction rather than hiding the lag.

A lock is needed because concurrent correctness can produce a wrong whole

Each individual action in a transfer can be authorised and still combine into an unsafe result. A seller may modify a ROA while a registry officer reviews the transfer. A buyer may change transit providers after submitting its intended origin. An automated certificate renewal may race with resource removal. A delegated CA may publish a new manifest while its parent changes the certified resource set. The actions are locally valid but globally inconsistent.

A transaction lock should therefore cover certification changes for the exact affected resources from final preflight until predecessor retirement. The lock does not stop routing or ordinary incident response. It prevents uncoordinated creation, modification or deletion of authorisations that would change the agreed handover state. Emergency changes require named authority, a recorded reason and renewed validation of the plan.

The lock should be granular. A transfer of one prefix must not immobilise unrelated resources held by the same organisation. Where a ROA contains several prefixes, the issuer may need to replace it with separate entities before transfer so that revoking authority for one resource does not disturb the rest. Current guidance favouring focused ROAs supports operational clarity here: a multi-prefix entity creates a larger change surface than the transaction requires.

The lock should also bind both interfaces and underlying authority. Preventing a seller from clicking an edit control is limited public evidence if delegated credentials can still publish a conflicting entity. Preventing new entities while allowing a scheduled renewal to recreate an obsolete configuration is equally weak. Hosted and delegated systems require different enforcement, but both should produce the same guarantee: the approved handover state cannot be silently changed by a concurrent action.

Lock release requires evidence, not elapsed time alone. The successor entity is valid, the old authority is gone, the intended route is observed and unresolved exceptions have an owner. If release occurs automatically after a fixed period, a delayed publication can turn a safety device into a false assurance.

Publication must be coherent before it can be quick

RPKI repositories distribute certificates, revocation lists, manifests and signed entities. A replacement ROA copied to a location without a matching current manifest is not a completed publication. A revocation list that validators cannot associate with the intended publication state does not reliably extinguish authority. The repository view has to be internally coherent.

RFC 9286 requires a new manifest when changes to a publication point are finalised, with hashes updated for replaced entities and relevant end-entity certificates revoked. RRDP represents repository changes through serialised snapshots and deltas; RFC 8182 recommends that changes for one CA key pair, including updated entities, manifest and revocation list, be sent as one atomic update message. These controls provide local publication consistency, which is indispensable but narrower than global transfer atomicity.

The distinction matters. A source CA can publish a perfectly coherent withdrawal while a destination CA has not yet published its coherent addition. Two repositories can each be internally correct and jointly create a gap. Conversely, the destination addition can arrive while the source withdrawal is delayed, creating overlap. An inter-regional move can also shift the resource between trust-anchor trees, so no single repository serial contains the complete change.

The handover coordinator should consume repository receipts from both sides. Each receipt should identify the certification path, manifest number or equivalent current-state marker, entity hash, publication time and affected payload. It should then obtain observations from independent validators. This does not make the Internet synchronous; it turns an uncertain sequence into an auditable one.

Speed is still valuable. Shorter intervals reduce exposure to gaps and residual authority. But a quick partial update is not safer than a slightly slower coherent one. Performance targets should begin after the inputs are complete, distinguish CA generation from repository publication and validator observation, and report the cases included. A global propagation promise cannot be inferred from one operator's cache.

Revocation is a governance act because it changes what relying parties may trust

The old ROA can cease to validate in several related ways. Its end-entity certificate can be revoked. Its issuing resource certificate can be replaced or revoked as the resource leaves the old holder. The entity can be withdrawn from the publication point and the manifest updated. Expiry can eventually remove it, but waiting for expiry after an effective transfer is not a responsible handover strategy.

Revocation should target the minimum necessary authority while ensuring the transferred resource is no longer covered by the old chain. If one certificate or entity covers unrelated resources, preparatory separation may be needed. A broad revocation that accidentally removes valid authorisations for retained prefixes converts transfer safety into collateral outage.

The timing is equally exacting. Revoking before successor visibility risks a break. Revoking long after successor visibility grants an unnecessary overlap. The right trigger is a set of observations: the new certificate chain validates, the intended payload is present, the live origin agrees, and the destination can respond to incidents. The old authority should then be retired without delay and the retirement observed.

RFC 8211 is useful because it analyses adverse CA and repository actions without assuming malicious intent. A CA error, repository error or policy action can diminish a holder's certified resources; a competing ROA can also affect routing outcomes. Transfer controls should therefore work under ordinary mistakes as well as hostile behaviour. Dual approval, signed event references and independent validation reduce the ability of one erroneous action to define the whole event.

An old authorisation surviving too long should be treated as an exception with a clock and accountable owner. The record should identify why it remains, which origins it permits, who can remove it and what interim monitoring applies. Calling it eventual consistency is not a remedy. Eventual consistency without an enforced terminal state is simply residual authority with a technical name.

Validator caches make convergence observable but never universal

Relying parties do not consult the issuing service afresh for every BGP update. They retrieve repository data, validate certification paths and signed entities, retain usable state under defined conditions, and provide validated payloads to routers. Polling intervals, repository availability, transport behaviour, software versions and local policy create different observation times.

RRDP is designed to help a relying party determine whether its local copy is synchronised with a repository by using a session identifier and serial number. Deltas can carry new, replaced and withdrawn entities in one change set. Yet one validator may fetch the latest delta while another experiences a failed retrieval and continues from a prior usable cache. A third may reject the new state because a manifest, hash or certificate check fails. Those are not theoretical violations of the transfer record; they are part of the environment the record must accommodate.

For this reason, a registry should not stamp a universal propagation time on every handover. It can publish service-level measurements for its own CA and repository. A transfer service can define a minimum observation set across independent implementations, transports and locations. An operator can choose a conservative hold period based on measured validation cycles and route criticality. None supplies the denominator of every relying party on the Internet.

Observation should preserve disagreement. If four selected validators see the new payload and one retains the old, the report should show five results, software versions, trust-anchor paths, fetch times and relevant errors. Averaging them into a green percentage would conceal the precise failure that matters. The stale result may identify a repository edge, a validator defect, an operational misconfiguration or an expected cache rule.

The terminal claim should be bounded: all named observation points validated the successor and rejected the predecessor by stated times. That is strong evidence. It is not proof that no disconnected, abandoned or privately modified validator retains old data.

Intra-regional and inter-regional transfers require different choreography

Within one RIR, a resource may move between organisations under the same regional trust anchor. The parent authority can update the resource sets of source and destination certificates within one institutional domain. Hosted services may automate much of the change. Even then, separate publication points and relying-party caches prevent true global simultaneity, and delegated CAs add operational coordination.

An inter-regional transfer changes more. The source RIR must remove the resource from its certified hierarchy and the destination RIR must add it under another hierarchy. Validators begin from different TALs and traverse different repositories. Source release and destination acceptance are governed by separate regional procedures, legal relationships and operational teams. The route may remain the same while its validation path moves between trust anchors.

The common transaction reference is therefore more valuable across regions. It should bind the exact prefix, source and destination authorities, intended route payload, release condition, acceptance condition and rollback boundary. Each RIR should issue its own signed or otherwise verifiable receipt. The transfer parties should be able to show that the destination was ready before the source made an irreversible withdrawal, or that an agreed continuity mechanism covered the interval.

Inter-regional overlap deserves careful interpretation. The same intended payload briefly validating under both regional paths can support continuity. Different origin payloads under the two paths create dual authorisation and should be time-bounded. A resource appearing under both trust anchors beyond the controlled handover can indicate a certification inconsistency that validators and RIRs need to resolve.

No universal legal or operational rule can be inferred from one RIR's interface. The shared standard should define interoperable event evidence and safety outcomes while leaving each authority responsible for its policy decisions. Coordination is not centralisation; it is the minimum structure needed when one route's authority crosses two institutional trees.

Hosted and delegated certification fail in different ways

Hosted RPKI gives the registry or service operator direct ability to update certificates and ROA configurations when registration changes. This can reduce coordination steps. RIPE NCC documentation explains that certified resources are updated automatically when resources move and that published ROAs are adjusted when resources are removed. The benefit is tight coupling between the holder record and hosted certification.

The same coupling can surprise a recipient that has not prepared replacement authorisations. Automatic removal is correct from the old holder's authority perspective but can still create an operational gap. The service should therefore require an intended-routing declaration or provide a pre-transfer warning and successor preparation path rather than relying on the buyer to discover the effect afterward.

Delegated RPKI shifts key and publication control to the resource holder or its service provider. The registry changes the parent certificate, while the transfer parties must coordinate their child CAs, publication points and entities. This can improve operational autonomy but expands the handover surface. A source delegated CA may be unreachable. A destination repository may not yet be accepted. Parent updates and child publication can race.

The safety outcome should be the same. The old chain stops validating the resource; the new chain validates the intended payload; no unplanned interval leaves the live route Invalid; and residual authorisation is bounded. The evidence differs. Hosted systems can provide internal event receipts and external validator observations. Delegated systems also need proof from publication servers and confirmation that the destination CA was operational before parent authority moved.

Transfer contracts should name the mode. A buyer who assumes hosted automation while receiving delegated responsibility may not possess the keys, service arrangement or expertise needed at cutover. A seller who assumes the registry will delete every old entity may retain a delegated publication state that becomes invalid but remains operationally confusing. Clarity about control is a prerequisite to continuity.

Rollback must preserve authority rather than recreate the past inaccurately

Before the effective holder change, rollback is relatively simple. Stop the transfer, remove any bridge authority that is no longer needed, release the certification lock and confirm that the original route state remains valid. Even here, removing the bridge requires the same publication and observation discipline as any other revocation.

After the resource has moved and the old certificate has been revoked, rollback is not a matter of restoring files from a previous cache. The prior entities may no longer possess a valid certification path. Reusing old keys or republishing expired states could create misleading authority. If the transaction itself must be reversed, the registry needs a new authorised change that re-establishes the former holder and issues current certificates and ROAs through a fresh sequence.

The point of no return should be explicit. It may be the source RIR's final release, the destination's certificate issuance, a legally effective transfer or a combination under applicable procedure. Before that point, an abort returns to the original state. After it, a remedial transfer or correction creates a new state. This distinction preserves history and prevents operators from hiding a failed event through silent restoration.

Operational continuity during remediation may require temporary authorisation by the current recognised holder for the origin that can keep service running. That decision should be separated from the dispute about ultimate holdership. A court or registry may restrain further transfer while permitting a bounded route authorisation to protect customers. The ROA records the route permission; it does not settle the dispute.

Exercises should test both paths. A service that has rehearsed only a successful cutover does not know whether it can stop safely before completion or recover afterward. Test cases should include wrong ASN, wrong maximum length, destination repository failure, stale source authority, unresponsive transferor and disagreement between observation points.

Legal restraints and sanctions should narrow the action, not corrupt the sequence

A transfer can be delayed or restrained by litigation, insolvency, sanctions review, fraud investigation or a dispute over authority. These conditions do not eliminate the need for accurate routing authority. They change who may instruct which action and when the holder state can move.

The event record should represent a restraint precisely. A prohibition on changing the recognised holder is not automatically an instruction to revoke the current ROA. An order preserving network service is not necessarily permission to complete the sale. A sanctions restriction on a recipient does not authorise a private intermediary to take the resource. Each condition should identify its source, scope, reviewer and expiry or review point.

Where a transfer is paused before effective change, existing valid authorisations can continue if lawful and operationally intended. Any bridge created for the proposed recipient should be reviewed because its purpose may no longer exist. Where a restraint arrives after effective change but before old authority is retired, leaving the transferor's ROA active is not a neutral response. The competent decision-maker should specify whether continuity requires a particular origin while the registration state remains current.

The cryptographic sequence must follow the authorised institutional state, not attempt to decide it. Certification authorities verify that the party recognised under their rules may make the statement. They should maintain an accurate history, preserve evidence and execute scoped decisions. They should not turn a broad legal uncertainty into two indefinite current authorities.

This is another reason to separate overlap from ownership language. Two ROAs may be temporarily valid because continuity was planned or a restraint required it. That does not mean two parties own the resource. One ROA may be revoked because certification authority moved. That does not prove every commercial obligation was satisfied. Exact statements reduce both technical and legal overreach.

Independent observation should test the route, the payload and the chain

A transfer monitor that checks only whether a ROA filename exists will miss the failures that matter. It should validate the complete chain from accepted trust anchor through resource certificates and the ROA's end-entity certificate, current manifest and revocation state. It should derive the resulting payload and compare that payload with the observed BGP route.

The monitor should answer four questions. First, is the intended prefix-origin-maximum-length tuple valid under the recipient's current chain? Second, does any former or unexpected chain still produce a payload for the transferred resource? Third, what validation state does the live route receive at each observation point? Fourth, do the registration and certification receipts identify the same resource and effective event?

Multiple implementations are useful because a parser defect or exceptional-condition decision in one validator should not define the report. Multiple locations are useful because repositories and network paths can fail differently. Multiple times are necessary because a single successful fetch does not show that predecessor authority was later retired. The observation set should be declared before cutover so that parties do not select only favourable results afterward.

Raw commercial documents need not be public. The public or member-facing record can disclose the prefix, old and new authorisation states, event times, participating authorities, observation method and unresolved caveats. Sensitive identity proofs and transaction terms can remain protected with audit access. The goal is verifiable operational closure, not indiscriminate disclosure.

Alerting should be event-specific. A notification that an old payload remains valid after its deadline is different from a notice that the new route is Invalid at one validator. The former demands revocation or parent-certificate investigation; the latter may indicate propagation, repository or route-configuration error. Exact alerts shorten remedy and clarify accountability.

Number Resource Society can standardise the receipt without pretending to be the root

A future Number Resource Society has a constructive role between fragmented transaction practice and concentrated certification authority. It can define a common handover receipt that RIRs, qualified providers, holders and independent monitors can produce and verify. The receipt would not replace a resource certificate or become a new ROA. It would bind the evidence that those authoritative changes occurred as one governed event.

The minimum fields are concrete: transfer reference, exact resources, source and destination registration authorities, old and intended origins, maximum lengths, hosted or delegated mode, bridge purpose, effective point, source release, destination acceptance, successor publication observations, predecessor revocation observations, exceptions and final reviewer. Each statement should identify its issuer and time.

NRS can also publish conformance tests. A provider should demonstrate a same-origin continuation, an origin change, an inter-regional move, a delegated-CA failure, a bridge abort and a post-effective correction. Test outputs should show validation results across named implementations rather than a single pass label. An accreditation claim would then refer to tested capabilities and current audit, not institutional affiliation.

This is positive decentralisation. Multiple providers and observers can implement the standard while RIR CAs remain accountable for their authoritative certification acts. Holders receive portable evidence of what occurred. Operators receive a common set of cutover states. Researchers can compare bounded performance without demanding private sale terms.

NRS should not promise that its receipt causes global validators to update, and it should not acquire the power to sign every route. Its legitimacy would come from making authority transitions more visible, exact and contestable. A standard that exposes a lingering old ROA is useful even when NRS lacks power to revoke it; the exposure tells the responsible CA and transfer parties precisely what remains unfinished.

Transfer economics improve when residual authority becomes a disclosed liability

Buyers price what they cannot control. If a seller can remain cryptographically authorised after closing, the buyer inherits a route-origin risk that ordinary title language may not cure. If the buyer's new route can become Invalid during cutover, customers may experience disruption just as the buyer takes responsibility. Lenders, insurers and operational partners should therefore treat RPKI handover as part of completion evidence for routed resources.

The remedy is not a universal price discount. Prefix reputation, route design, contractual rights, regional policy and market conditions differ. There is no complete global denominator for transfers with ROA gaps, stale authorisations or customer impact. Private sales and routing arrangements are not fully observable. Any claim that a fixed share of address value is attributable to clean RPKI handover would exceed the evidence.

The transaction can nevertheless allocate responsibility clearly. The seller warrants that it has disclosed existing authorisations and cooperates in bridge creation and retirement. The buyer supplies intended routing data and maintains destination certification readiness. The registry or provider commits to coherent holder and certificate changes. A closing condition requires named validator observations. A retained amount or indemnity can address failure to retire predecessor authority, subject to applicable law.

These terms convert technical ambiguity into manageable duties. They also make service quality comparable. A registration provider that can produce bounded handover receipts, fast coherent publication and effective exception response offers more than a portal. An observer that preserves divergent results offers more than a green badge. A broker that checks route authority before and after closing reduces a real operational risk.

The economic benefit comes from smaller uncertainty, not from turning ROAs into property deeds. The cleaner the separation between holder change, route permission and observed closure, the easier it is for each party to accept the risk it can control.

Accountability requires publishing the exceptions, not only the median

A mature transfer service should report performance using the population it actually processed. For each period it can state how many transfers used a same-origin continuation, changed origin, crossed RIRs, used delegated certification or required an exception. It can report completion intervals from defined start and end events and show unresolved predecessor authority at the reporting cut-off.

The exceptional cases matter most. A single old ROA that remains valid after transfer can expose the weakness hidden by many routine successes. Reports should explain whether the cause was transferor inaction, hosted-service defect, delegated publication failure, parent-certificate timing, destination unreadiness, legal restraint or validator disagreement. Personal and commercial details can be minimised without erasing the institutional cause.

Denominators must remain local to the report. The participating transfers do not reveal all transfers worldwide, all private leases or all unreported interruptions. Validator observations do not reveal every network's routing policy. BGP visibility does not prove the complete contractual relation. Honest bounds make the findings more useful because operators know what can and cannot be inferred.

Independent review should sample complete event histories, not screenshots of final status. The reviewer needs to see the declared plan, lock, authority evidence, publication receipts, observations, revocation and exception handling. It should verify that timestamps come from identified systems and that the final reviewer did not approve a case with unexplained residual authority.

Members should be able to challenge a report. If a transfer party shows that an old payload remained valid at a named observation point, the service should investigate rather than dismiss the result because most monitors were green. Institutional legitimacy is built by repairing the outlier that exposes a control gap.

The safe terminal state is simple even when the path is not

At the end of a transfer, the recipient is the recognised holder under the applicable registry arrangement. The recipient's certification path covers the transferred resource. The intended route-origin payload validates through that path. The live BGP route matches the intended prefix, origin and permitted length. The transferor's former path no longer validates authority for the resource, except for no stated purpose because the bridge has ended. Independent observations record the result and any unreachable vantage point honestly.

Reaching that state can require regional coordination, legal review, delegated operators and several validation cycles. Complexity is not a reason to weaken the terminal condition. It is a reason to define intermediate states, assign owners and preserve evidence.

The lesson of the old ROA is not that overlap must never occur. Make-before-break often requires overlap. The lesson is that overlap must have a purpose, a narrow scope and a forced ending. Nor is the lesson that every gap will disconnect the prefix. Some networks may accept NotFound routes, and routing can persist through an Invalid interval where filtering is absent. The objective is not to gamble on inconsistent policy; it is to preserve intended authorisation.

Since 2012, the technical architecture has contained the essential sequence. The institutional task is to apply it to transfer as a whole. Registration officers, CAs, repositories, transfer parties, operators and relying parties each see only part of the event. A handover standard makes those parts answer to one completion test.

The transfer is not cryptographically closed when the registry sends its confirmation. It is closed when successor authority works, predecessor authority no longer works, the live route agrees and the evidence can be replayed by an independent reviewer. Anything less leaves either a reachability gap or a former holder's shadow at the routing table.