Update to “Resource Recovery and Return” and consistency with the rest of the Manual

Proposal scope and identified policy-improvement items · The new version expressly links the proposal to items 1, 8, and 10 on the cited list of potential improvements; the old version referred to potential improvements without identifying numbered items or providing that link.

Whois information as a ground for resource revocation · The revocation ground for failing to update allocation and assignment information is expanded from LACNIC's Whois database alone to the Whois database managed by LACNIC or the NIRs, as applicable.

Third-party-caused violations · Where a violation was caused by a third party without the recipient's knowledge and there is no collusion or negligence, the old text said the revocation process would not be completed; the new text says the process will not be initiated.

Use of recovered or returned IPv6 and ASN resources · The old text placed IPv6 and ASN resources into their respective pools two years after recovery or return. The new text retains the two-year rule but additionally authorizes LACNIC to use the resources differently according to best practices to optimize compliance with RFC 7020, including treatment of recovered or returned 16-bit ASNs.

Non-guaranteed routability policy · The old draft's consolidated routability provision was limited to allocated or assigned IPv4 addresses. The new draft applies non-guaranteed routability to allocated or assigned addresses generally and incorporates the requirement that RIRs use operational procedures reducing address-space fragmentation and routability-loss risk.

Proper administration and stewardship requirements · The old draft stated that resources must be distributed among qualifying regional organizations and added a requirement to become a LACNIC or corresponding RIR member and sign the Registration Services Agreement. The new draft instead says resources must be allocated to qualifying organizations, removes that membership-and-signature sentence, and adds that obtaining any resources from LACNIC or the corresponding NIR causes the recipient's legacy resources to cease being considered legacy resources.

Resource-request procedures · The old draft eliminated the IPv4 application-template section as an operational mechanism common to all resources without supplying replacement policy text. The new draft adds a general Resource Requests section stating that requests to LACNIC or the corresponding NIR will use systems in force and that incomplete requests will be returned with completion instructions.