Se establecen los cambios editoriales propuestos por el autor en la lista de políticas https://mail.lacnic.net/pipermail/politicas/2022-May/006497.html.
Se eliminan las palabras “cliente” y “certificados” del tercer párrafo del texto de la propuesta “Mientras se mantenga el registro de los bloques de prefijos en la base de datos de WHOIS, el cliente receptor dispondrá sobre dichos recursos la facultad para la creación y administración de los certificados Route Origin Authorization (ROA) de RPKI.”

LACNIC Staff's Interpretation of the Proposal

Applicability:
This proposal introduces changes to the Policy Manual.

Rationale:
The problem that this proposal seeks to solve is that those who receive prefixes delegated by their providers are unable to sign the ROAs for those prefixes.
Modifications to the current text:
This proposal modifies the Policy Manual, adding a paragraph to Section 2.3.2.13, Registering assignments.

Proposed Text:
2.3.2.13. Registering assignments
All IPv4 address block assignments of a /29 or larger block made by an ISP to customers connected to their network and users of services provided must be registered on LACNIC's WHOIS database not more than 7 days after the assignment.
The information available in the WHOIS database will also be used by LACNIC when analyzing additional IPv4 address requests submitted by the ISP.
As long as the prefixes are registered in the WHOIS database, the receiving client will have the right to create and manage the RPKI Route Origin Authorization (ROA) certificates for said resources.
Assignments must also be registered for the following reasons:
To ensure that the IR has completed or is close to completing address space allocation such that the allocation of additional space is justified.
To inform the Internet community which organization is using the IPv4 address space, including their point of contact in case of operational, security or other types of issues.
To study IPv4 address allocation in the region.
To facilitate the geolocation of sub-assignments made by members in our region.

LACNIC Staff Comments:
LACNIC understands that, when a member eliminates a sub-assignment, the associated ROAs will be revoked.

LACNIC Staff Recommendations:
For reasons of consistency with the terminology used in the policy manual and to clarify the use case, we recommend either removing the term “client” and using “recipient” or substituting the phrase “the receiving client” with “the organization holding the sub-assigned resources.”

Official References:
RIPE NCC: The registry only allows this in “delegated mode.”

Impact of the policy on the registry and/or other systems:
If this policy proposal is approved, several LACNIC systems will be affected, including the RPKI system and MiLACNIC. If this policy is approved, the time frame for its implementation will be informed through the mailing list.

Impact on NIC.br and NIC Mexico:
Because NIC.br uses the delegated model, any entity that receives assignments and wishes to use RPKI must establish and configure its own Certificate Authority (CA). If this proposal is approved, the entity that receives the sub-assignments will also have to configure a CA and be part of the validation chain. To do so, its provider will have to issue a child certificate with the assigned resources. The provider will also have to provide the repository service to their client. Another aspect worth noting is that the provider will have to create mechanisms to follow up on the sub-assignments that appear in the child certificates it has issued. This is because, if these are canceled, the certificates that have been issued must be updated in a synchronized fashion. Otherwise, there is a risk of authorizing the creation of ROAs by companies that no longer have the right to use a sub-assignment.
The impact for NIC Mexico is similar to the impact for LACNIC, as they use the same systems to generate ROAs.