Permission to Transfer and Non-Return of Resources - N/A

General information

Español
20/03/2022
Implemented
100 %.

Jordi Palet Martínez - Version [1, 2]
In discussion
30/03/2022 - 25/05/2022
First consensus
25/05/2022 - 08/06/2022
Last call for comments
08/06/2022 - 06/07/2022
Second consensus
06/07/2022 - 13/07/2022
Ratification by the board
12/07/2022
Ratified
02/08/2022
Implemented
03/08/2022

Public comments by LACNIC staff for this version

LACNIC Staff's Interpretation of the Proposal

Author: Jordi Palet

Applicability:
This proposal establishes changes to the Policy Manual relating to IPv4 address allocation and assignment.

Modifications to the current text:
This proposal adds a new paragraph, “2.3.6. Permission to Transfer and Non-Return of Resources”, to the Policy Manual under section “2.3. IPv4 Address Allocation and Assignment Policies.”

Proposed Text:

2.3.6. Permission to Transfer and Non-Return of Resources

While address allocation and assignment policies are initially based on the justification of need, in practice, the introduction of transfers means that it is no longer necessary to maintain this justification. Therefore, even in case of failed transfers, returning the resources to LACNIC will no longer be required in case of failed transfers or mergers and acquisitions.

LACNIC Staff Comments:
1) This proposal is a timely idea, as it clarifies various sections of the Manual.
We also reiterate that LACNIC interprets that the permission to transfer and non-return already exists and is being carried out.
When initiating a transfer process, LACNIC verifies that the offering party meets all resource transfer requirements. The policies currently in force do not require the offering party to specify the reason for the transfer. We cannot assume that the reason for every transfer is that an organization no longer needs the addresses. Therefore, if a transfer is rejected, LACNIC does not require the resources to be returned.
There are multiple reasons that may lead an organization to transfer their resources, including the following:
- The organization wishes to advance in their IPv6 deployment and wants to free up some IPv4 space to finance the investment.
- They have the opportunity to use their IPv4 resources more efficiently.
- The opportunity to sell part of their client portfolio.
- They have legacy space, so the policies do not apply.
- They have financial needs and decide to cover these needs with part of their address space, even if this means degrading the quality of their services (NAT/CGN).

Recommendations:
No recommendations.

Impact of the policy on the registry and/or other systems:
No impact on the registry system or on the Policy Manual.


Summary

This proposal corrects an inconsistency between the requirement to justify the need for IPv4 resources and the possibility of transferring such resources.

The proposal also takes the opportunity to solve three aspects that appear in the IPv4 portion of the Policy Manual, but which clearly apply to all resources.

Rationale (Describe the problem you intend to solve)

When we approved LACNIC's transfer policies, we failed to consider that certain inconsistencies existed in the Policy Manual which created discrepancies in the text. Basically, resources are assigned based on need. However, if a resource recipient wishes to transfer their resources, it is because their need has disappeared. In this case, it would seem obvious that the reasonable thing to do would be to return rather than to transfer the resources.

Clearly, by approving the transfer policies, the community has accepted that it is preferable to transfer these resources so that others in need can use them, rather than demanding that the resources be returned – which would usually not occur or would be delayed in time. Furthermore, if a transfer is rejected for whatever reason, there would clearly be a breach of the needs-based requirement.

In addition, three sections included in the IPv4 portion of the Policy Manual (2.3.2.13.2. Geolocation, 2.3.2.14. Security and Confidentiality, 2.3.2.15. Equal Processing of All Applications) clearly apply to IPv4, IPv6, and even ASN resources, so the reasonable thing to do would be to move these texts to Section 1, Definitions. Because these are minor editorial changes, they can be fixed without the need to submit a separate proposal.

Current text

No such text exists.

2.3.2.13.2 Geolocation

In addition to the information available in the WHOIS database, the assignments made by LACNIC and the sub-assignments made by its members will be published in a file along with information on the country in which the prefix was assigned. This file will be available for the community to download freely. Among other uses, this file may be used to geolocate an IP address.

The file's format and the place where it will be published will be defined by the LACNIC staff.

2.3.2.14. - Security and Confidentiality

LACNIC shall maintain systems and practices that oversee and protect the confidentiality of all information entrusted to LACNIC in the documentation submitted to justify the allocation or assignment of IPv4 addresses.

2.3.2.15. - Equal Processing of All Applications

LACNIC shall process every application strictly in the order in which they are received, regardless of geographical factors, demographic factors, language, etc. Under no circumstance shall LACNIC grant special treatment or make exceptions to the norm established for application processing. For this purpose, LACNIC shall use an application numbering system that will allow their proper administration.

New text
Analyze diff

2.3.6. Permission to Transfer and Non-Return of Resources

While address allocation and assignment policies are initially based on the justification of need, in practice, the introduction of transfers means that it is no longer necessary to maintain this justification. Therefore, even in case of failed transfers, returning the resources to LACNIC will no longer be required and, instead, the resources must be transferred on successive occasions.

(Move to Section 1. Definitions)

1.x. Geolocation

In addition to the information available in the WHOIS database, the assignments made by LACNIC and the sub-assignments made by its members will be published in a file along with information on the country in which the prefix was assigned This file will be available for the community to download freely. Among other uses, this file may be used to geolocate an IP address.

The file's format and the place where it will be published will be defined by the LACNIC staff.

(Move to Section 1. Definitions)

1.x. Security and Confidentiality

LACNIC shall maintain systems and practices to safeguard and protect the confidentiality of all information entrusted to LACNIC, for example, the documentation submitted to justify resource requests.

(Move to Section 1. Definitions)

1.x Equal Processing of All Applications

LACNIC shall process every application strictly in the order in which they are received, regardless of geographical factors, demographic factors, language, etc.

Under no circumstance shall LACNIC grant special treatment or make exceptions to the norm established for application processing. For this purpose, LACNIC shall use an application numbering system that will allow their proper administration.

Additional information

In several RIRs, legal documents (service agreement) and/or policies have already been modified to avoid contradictions between the need to return any resources whose use is not justified and their transfer.

Timetable

-

References

-

Presented at:

LACNIC 36 (11/10/2021)


Summary

This proposal corrects a lack of clarity or inconsistency between the requirement to justify the need for IPv4 resources and the possibility of transferring such resources.

Rationale (Describe the problem you intend to solve)

When we approved LACNIC's transfer policies, we failed to consider that certain inconsistencies existed in the Policy Manual which created discrepancies in the text. Basically, resources are assigned based on need. However, if a resource recipient wishes to transfer their resources, it is because their need has disappeared. In this case, it would seem obvious that the reasonable thing to do would be to return rather than to transfer the resources.

Clearly, by approving the transfer policies, the community has accepted that it is preferable to transfer these resources so that others in need can use them, rather than demanding that the resources be returned – which would usually not occur or would be delayed in time. Furthermore, if a transfer is rejected for whatever reason, there would clearly be a breach of the needs-based requirement.

Current text

No such text exists.

New text
Analyze diff

2.3.6. Permission to Transfer and Non-Return of Resources

While address allocation and assignment policies are initially based on the justification of need, the implementation of transfers eliminates the need to maintain this justification. Therefore, returning the resources to LACNIC will no longer be required in case of failed transfers or mergers and acquisitions.

Additional information

In several RIRs, legal documents (service agreement) and/or policies have already been modified to avoid contradictions between the need to return any resources whose use is not justified and their transfer.

Timetable

-

References

-

Presented at:

LACNIC 37 (04/05/2022)

--> --> --> --> --> -->