Summary

  • LACNIC’s 2024 and 2025 event surveys report that 48% and 80% of respondents to the second survey module said they attended the secure-routing and origin-validation lab. The reports do not show the tutorial question’s respondent count beside those percentages.
  • LACNIC 46’s announced lab moves from manual BGP-announcement review to RPKI automation and filtering. That is a plan for a practical exercise, not evidence that participants completed it or changed a production network.

Analysis

An attendance measure has a narrow denominator

LACNIC’s satisfaction report for LACNIC 42 places the secure-routing and origin-validation lab at 48% in its total column. The corresponding LACNIC 43 report places it at 80% and says the lab led tutorial participation across the groups it analyzed. In each report, the tutorial question is based on people who answered the survey’s second module. The full reports list 373 and 504 cases respectively, but those are the overall survey samples; neither report prints the number of answers to this tutorial question alongside the chart.

The figures therefore describe reported attendance among a survey subpopulation. They are not the percentage of everyone registered, the percentage of all network operators in the region, or a measured share of production networks with RPKI-based filtering. Nor should 48% and 80% be read as a two-year adoption curve. The events had different samples and programme menus, and the survey does not follow the same people or networks across editions. The defensible signal is narrower: among people answering the relevant module, the lab drew substantial reported participation.

The exercise is a control sequence, not a deployment receipt

LACNIC’s April 2025 preview described a simulated lab in which participants could configure RPKI validators, apply filtering policies and automate related tasks with Ansible. Its October 2026 agenda preview describes a related exercise in a different sequence: inspect BGP advertisements manually, then introduce automation engines for RPKI configuration and filters intended to help mitigate attacks. The event API lists the session for Monday 19 October at LACNIC 46. At the research cutoff, that event is still in the future.

The sequence matters because routing security is not one switch. An operator observes an announcement, evaluates the origin against validated prefix authorizations, and decides how local policy will treat the result. RFC 6811 distinguishes Valid, Invalid and NotFound origin-validation states. The validation result does not itself install a filter, and origin validation does not certify every autonomous system on a path or prevent every route leak. The router policy and its operating context determine what happens next.

A virtual lab can make that chain teachable without exposing a live network to an experiment. It can let an operator compare expected and observed states, test a policy, and see whether an automation step changes the intended configuration. But a scheduled exercise, a successful simulation, and a durable production control are separate outcomes. The public preview describes the first; it does not report the latter two.

What the public evidence does not connect

The satisfaction surveys ask which tutorials respondents attended. They are useful evidence about programme reach and participant interest. They do not ask, in the published tables, whether each respondent completed every lab stage, retained the material, deployed a control later, or had a production change independently checked.

That absence is not evidence that LACNIC lacks internal evaluation, that the lab failed, or that no participant adopted a practice. It is a boundary in the public record reviewed here. Without a visible denominator and a follow-up measure, readers cannot distinguish interest from completion or completion from implementation. And even a subsequent RPKI or BGP observation would not, by itself, establish that the lab caused the change.

A receipt can separate four different results

The useful next record is modest. For the exercise itself, LACNIC could publish the lab version and tool versions, the test announcements and expected validation states, the policy and filter actions participants were asked to apply, and the observed completion, error and rollback counts. Each count needs its own denominator. A result such as “participants configured a filter in the simulation” would then mean exactly that—not that a regional network adopted it.

A separate, voluntary follow-up could ask whether a participant adapted a control in a live network, when it was introduced and what evidence supports the answer. The report should identify the number invited, the number responding and any self-selection limits. It should avoid collecting confidential configurations or implying that a public route change belongs to a particular attendee. A public measurement of route state can show what the network announces; it cannot identify why an operator changed it.

This is a clearer test of training than attendance alone, while keeping responsibility in the right place. LACNIC can document the exercise it designs. Each operator controls its own production configuration. Better records would show what the lab taught and what participants chose to do, without promising that a course can secure an entire region.

LACNIC 46 offers a timely opportunity to make that distinction explicit before the session takes place. Its manual-to-automated sequence is concrete enough to report as a test. The next public number should tell readers whether that test was completed, what failed, and whether any later operational use was voluntarily reported—not turn a full room into a security outcome.

Sources