Temporary Transfers

Separate public logs for permanent and temporary transfers · Version 2 replaces the single transfer log with a permanent-transfer log and a separate equivalent temporary-transfer log containing start and end dates. Version 1 used one log with an empty end date for permanent transfers. Both retain public visibility of temporary transfers.

Thirty-day extension request deadline removed · Version 2 removes the requirement to request an extension at least 30 days before the agreed end date. It retains formal endorsement by both parties and verification by LACNIC before updating that date. The revised clause sets no replacement minimum notice period.

Recipient conditions and originator oversight made explicit · Version 2 expressly assigns the ASN, operational IPv6, RPKI, geolocation/IRR and MANRS conditions to the receiving entity, requires their guarantee in the parties’ agreement and makes the originating entity responsible for oversight. It also permits LACNIC to establish operational compliance practices. The technical conditions themselves largely remain from version 1.

Warning before revocation for failed due diligence · Version 2 replaces the statement that failure of the additional conditions is immediate grounds to revoke the transfer with a due-diligence mechanism aimed at the originating entity. LACNIC may warn that entity, including for failures across different transfers or recipients; ignoring the warning may lead to immediate revocation of the resources involved.

An IPv6 deployment plan becomes sufficient · Version 3 allows the recipient to have either operational IPv6 or an IPv6 deployment plan. Version 2 required operational IPv6 when announcing the transferred IPv4 resources. The change introduces a planning alternative and removes that explicit announcement-time operational prerequisite.

Recipients cannot originate onward transfers · Version 3 adds an express prohibition on the receiving entity being a source of subsequent transfers. Version 2 required restoration of the original registration at the end of a temporary transfer but did not include this explicit onward-transfer prohibition.

Specific warning and revocation mechanism removed · Version 3 retains the originator’s responsibility for compliance oversight and LACNIC’s ability to establish operational practices, but removes the explicit warning followed by immediate resource revocation for ignored warnings. The omission changes the proposed enforcement text; it does not remove obligations under other applicable policies or agreements.

Technical recipient requirements become recommendations · Version 4 recasts the ASN, IPv6 or deployment plan, RPKI, geolocation/IRR and MANRS conditions as advisable requirements rather than mandatory conditions guaranteed by the parties’ agreement. The separate bar on onward transfers remains. The revised list should therefore not be presented as five mandatory eligibility tests.

Revocation clauses broadened and originator oversight omitted · Version 4 requires revocation clauses for resource abuse or other policy violations and states that they protect the original holder from repercussions. Version 3 referred to misuse or abuse and separately assigned oversight to the originator. Version 4 omits that oversight sentence and LACNIC’s operational-practices sentence; its protective wording is a proposal claim, not proof of legal immunity.

Sub-assignment treatment introduced in explanatory material · Version 4 adds operational guidance that temporary transfers may be treated as sub-assignments while remaining distinguishable from ordinary sub-assignments. This appears in additional information, while the proposed policy still uses the temporary-transfer framework. It does not yet expressly waive a connectivity requirement in the operative text.

Standalone temporary-transfer section and connectivity exception · Version 5 replaces the proposed combined permanent-and-temporary transfer section with a separate section 2.3.2.19 for temporary transfers. It expressly treats these as sub-assignments without requiring connectivity on the same physical infrastructure, including an explicit end-user sub-assignment exception. The intra-LACNIC scope and /24 minimum remain.

Simplified recipient justification and no stated /20 ceiling · Version 5 replaces the ordinary initial/additional allocation justification and explicit aggregate /20 recipient ceiling with a simplified demonstration that the recipient lacks sufficient addresses for its needs. It gives examples and lets LACNIC specify a procedure if necessary. The new temporary-transfer section contains no replacement /20 cap.

Public-log details and extension procedure no longer prescribed · Version 5 retains a public temporary-transfer log for traceability but omits the detailed field list, explicit start/end-date requirements and extension procedure requiring both parties’ endorsement and LACNIC verification. These details are no longer prescribed by the new section; the general traceability obligation remains.

Automatic restoration of registration omitted · Version 5 omits the explicit instruction to restore pre-transfer registration values on the temporary transfer’s end date. It instead introduces operational treatment as a sub-assignment. The rationale still envisages return of the addresses, but that intention must not be reported as the same operative restoration instruction found in version 4.

Both parties must have executed the service agreement · Version 5 expressly requires both transferring and receiving entities to have executed the service agreement. Version 4 stated that both were subject to the relevant RIR’s policies and membership terms but did not add this explicit execution requirement.

Mandatory abuse-revocation clauses removed · Version 5 removes the requirement for transfer agreements to contain revocation clauses for abuse or policy violations, along with the statement about protecting the original holder. It still requires a signed legal document supporting the transfer and retains the parties’ general policy and agreement obligations.

Recommended technical conditions omitted · Version 5 omits version 4’s advisory list covering ASN, IPv6 or deployment plan, RPKI, geolocation/IRR and MANRS. The prohibition on the temporary recipient making onward transfers remains as section 2.3.2.19.8. The omission removes these recommendations from this proposal; it does not cancel independent obligations elsewhere.