Improving LACNIC Policies
In the interest of inspiring members of the LACNIC community to develop new policy proposals, we are publishing a list of suggested improvements to existing policies below.
Please note that each suggested improvement may not be a policy proposal requiring formal presentation as part of the Policy Development Process (PDP).
The purpose of this list is to help gauge community interest in certain areas. Our goal is to create synergy within the LACNIC community for the creation of new policy proposals. We hope that those listing needed improvements and those reading them will together find possible solutions, which can be submitted in the form of a policy proposal.
Anyone can contribute to the list below, adding any additional improvements they would like to see with regard to LACNIC policies.
- If you would like to suggest another improvement, please send it to email@example.com
- If you decide to write a policy proposal addressing one or more of these potential improvements, please submit it via politicas.lacnic.net
- If you wish to be put in touch with a policy shepherd* to guide you through the process of submitting your proposal, please contact firstname.lastname@example.org
*Policy shepherds are members of the LACNIC community with experience in the PDP who volunteer their time to help others submit proposals.
The LACNIC policy currently in force only addresses how bulk Whois data is to be used and how to request this data. Given the development and advances of the Registration Data Access Protocol (RDAP) in the LACNIC region, it would be good to have a policy that defines how to request access to RDAP data.
The current text has undergone dozens of modifications due to new proposals that have been approved and policies amended. Unfortunately, these changes have resulted in an exceedingly long document with various inconsistencies and repetitions (for example, some items are repeated in the IPv4 and IPv6 sections). Additionally, some parts of the IPv4 policy are no longer applicable now that the final phases of IPv4 exhaustion have been reached.
Section 220.127.116.11.1. Requirements for a /24 to /22 prefix
“(…) Si se ha justificado espacio adicional y es posible su distribución, el receptor podrá decidir si la cesión** (…)”
**By way of clarification for the purpose of LACNIC’s operations, to hand over (ceder in the Spanish original) is equivalent to a simplification of the transfer process, under which section 18.104.22.168.5 does not apply. In any case, it would not be possible to apply this section as LACNIC has no resources available for organizations other than new entrants to the LACNIC system.
An amendment to this policy is needed to clarify the term hand-over and to include the text specified after the double asterisk (**) above so that it will be part of the manual.
The terms ISP and end user are used in the policy manual. However, what is the current definition of an ISP? Are there any cases in which end users make sub-assignments?
It would be convenient to review the current use of these terms in the manual, and whether they are still applicable or need to be clarified and amended.
Reference: RIPE uses the concept of “LIR” (an organization that receives addresses from a RIR and distributes them) www.ripe.net/participate/policies/proposals/2018-01