LACNIC Staff's Understanding of the Proposal
Author: Jordi Palet Martínez
Applicability:
This proposal establishes changes to the Policy Manual relating to IPv4 address distribution and assignment.
Modifications to the current text:
This proposal would modify Policy Manual Sections “1. DEFINITIONS” and “2.3. POLICIES FOR THE ALLOCATION AND ASSIGNMENT OF IPv4 ADDRESSES.”
Text of the proposal:
This proposal adds a new item “2.3.6. Permission to Transfer and Non-Return of Resources” in Section “2.3. Policies for the Allocation and Assignment IPv4 Addresses” of the Policy Manual.
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.
This proposal modifies three sections of the Policy Manual (“2.3.2.13.2. Geolocation,” “2.3.2.14. Security and Confidentiality,” and “2.3.2.15. Equal Processing of All Applications”) and moves them 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 others, 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.
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.
1.x. Equal Processing of All Applications
LACNIC shall process each 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.
LACNIC Staff Comments:
1) LACNIC understands that the permission to transfer and non-return already exists and is being implemented.
When initiating a transfer process, LACNIC verifies that the offering party complies with 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 the fact that an organization no longer needs the addresses. Therefore, if a transfer is rejected, LACNIC does not require the return of the resources.
There are multiple reasons that may lead an organization to transfer their resources, including the following:
- They want to advance in their IPv6 deployment and want to free up some IPv4 space to finance their 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).
The idea of this proposal is timely, as it clarifies an inconsistency between sections of the Manual. However, we suggest wording this paragraph more clearly.
2) In the case of the texts included in sections 2.3.2.13.2, 2.3.2.14, and 2.3.2.15:
LACNIC understands that these are not definitions but mandates, so it would not be correct to move them to section 1.x. Furthermore, if the author decides to propose this discussion, he should submit an independent proposal, as it has no relation with the first aspect addressed by this proposal.
Consequently, in this impact analysis, we have decided not to review the changes proposed for these paragraphs.
If the community agrees that these changes should be discussed in an independent proposal, they will be analyzed in due course.
Recommendations:
1) Based on Comment #1, we suggest the following 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, the implementation of transfers eliminates the need to maintain this justification. Consequently, in case of failed transfers, mergers, or acquisitions, returning the resources to LACNIC will not be required.
2) We suggest eliminating the proposal to move sections 2.3.2.13.2, 2.3.2.14, and 2.3.2.15 to the Definitions section.
Impact of the policy on the registry and/or other systems
No impacts were identified in this version.
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.
Justificación(Describa el problema que pretende solucionar)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.
Texto actualNo 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.
Texto nuevo2.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 thex resources to LACNIC will no longexr be required and, instead, the resources must be transferred on successive occasions.2.3.2(Move to Section 1. Definitions)
13.2x. 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.(Move to Section 14. -Definitions)
1.x. Security and Confidentiality
LACNIC shall maintain systems and practices that over seafeguard and protect the confidentiality of all information entrusted to LACNIC, infor example, the documentation submitted to justify resource requesths.
(Move allto Secation or1. assignmDefinit iof IPv4 addrensses.)2.3.2.15. -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.
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.
Tiempo de implementación-
Referencias-
Presentado en:LACNIC 36 (11/10/2021)
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.
Justificación(Describa el problema que pretende solucionar)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.
Texto actualNo such text exists.
Texto nuevo2.3.6. Permission to Transfer and Non-Return of Resources
While address allocation and assignmexnt policies arex 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.
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.
Tiempo de implementación-
Referencias-
Presentado en:LACNIC 37 (04/05/2022)