Summary

  • LACNIC's 19 October 2026 MiLACNIC tutorial presented ASPA, delegated RPKI and a security-incident reporting module to direct resource holders. Its own programme says the material shown is unavailable to members of Brazilian organisations because their NIR uses another platform.
  • For Mexico, the programme identifies compatibility only for the RPKI and reporting modules. The 20-page teaching deck then shows what is actually inside the MiLACNIC door: administrator rights, mandatory second factor, notification choices, route authorisation and incident reports.

LACNIC put the catch at the bottom of its resource-management tutorial. Above it, the programme offers a respectable list: a portal for number-resource administration, ASPA declarations, delegated RPKI and a security module. Below it, the audience changes. The material shown would not be available to members of organisations in Brazil, because the region's National Internet Registries use a different platform. For Mexico, LACNIC names a narrower bridge: the RPKI and reports modules are compatible with the presentation. One regional registry; several front doors.

The distinction matters because these are controls an operator might need on a bad day. ASPA lets an autonomous system declare authorised transit providers so a validator can identify paths inconsistent with those relationships. Delegated RPKI lets an organisation run its own certificate authority under LACNIC's parent, retain its private key and create signed ROA or ASPA objects. The CSIRT module accepts information about number resources caught up in security incidents. The official slide deck puts all three in one MiLACNIC lesson. The platform qualification is in the official session description, not in the slides.

That division is easy to miss. A headline about “LACNIC rolling out ASPA” sounds like a single regional product launch. The programme actually targets organisations assigned IPv4 or IPv6 directly by LACNIC. It specifically warns that the demonstrated material is unavailable to Brazilian organisations on their NIR's different platform. It does not document what Brazil's own interface offers, when equivalent features might arrive there, or whether a given Brazilian operator can use another route. Those facts require first-party NIC.br service documentation or an operational record.

The evidence here establishes a teaching and portal boundary, not a verdict on every operator's routing security.

Mexico has its own carefully worded exception. LACNIC says the RPKI and reports modules are compatible with the tutorial. It does not say every MiLACNIC function, administrative workflow or alert channel is identical in Mexico. Compatibility for two named modules is a useful assurance precisely because the NIR architecture makes blanket statements unreliable. A procurement team planning RPKI operations needs to ask which portal receives the instruction, which user can sign it and which system records the change. Regional branding cannot answer that question.

The deck shows why the operator should care about the front door. Only an administrator can add or remove co-administrators. Co-administrators receive the administrator's permissions except editing contacts and adding further co-administrators. At least one second factor is mandatory; the slides describe TOTP setup, backup codes and SMS as backup. Notification choices are per user, with examples spanning new ROAs, password changes and GeoFeed edits, delivered through channels including email, app, SMS, Slack, webhook and WhatsApp. This is the practical control plane around a registry record.

A feature may exist in a policy deck; usable authority still sits behind a particular login, permission set and notification path.

The ASPA slide supplies another warning against checkbox security. It says transit providers belong in the declaration; peers, including IXP peers, and customers do not merely because a BGP session exists. It says active providers must not be omitted and former providers must be removed. That is an operational maintenance problem. A stale declaration can be worse than an empty launch announcement. Delegated RPKI shifts a different burden: the child CA controls its private key and signed objects while the parent-child chain uses the RPKI provisioning protocol. The portal can offer independence; the holder has to run it competently.

This is a precise institutional split. LACNIC coordinates the resources and presents security functions, while NIR platforms determine the route by which some members encounter them. The official programme's Brazil footnote is therefore part of the product specification, not small-print event housekeeping. If LACNIC wants a region-wide claim about practical availability, it needs a dated per-platform feature matrix and usage evidence. Until then the honest map has three labels: the direct MiLACNIC demonstration, Brazil's separate NIR platform, and Mexico's stated compatibility for two modules.