Summary

  • MANRS's Network Operators Program Review working group rejected a five-RIR-only IRR rule on 8 September after an estimate that nearly 40% of participants would fail it. Its 22 September detailed minutes put a five-IRR restriction at 13%, although that document's summary repeats nearly 40%.
  • The later meeting estimated that full RPKI coverage would affect 20% of members. Members discussed a RADB fallback, the difference between requiring RPKI and IRR or allowing either, and whether stricter requirements can be adopted without pushing existing operators out.

The percentage that walked into two rooms

At a routing-security meeting, a percentage can be as consequential as a prefix filter. MANRS wants network operators to document and validate the routes they announce. Its review group is discussing a stronger baseline. On 8 September, it rejected a proposal to recognize IRR registrations only in the five RIR-based routing registries: the impact assessment said nearly 40% of participants would fail. The group leaned toward those registries as its preferred signal while permitting RADB for legacy resource holders and others without RIR access.

Two weeks later, the 22 September minutes estimated that 100% RPKI coverage would affect 20% of members. The document's summary again says a narrow IRR list would affect nearly 40%. Its detailed account says limiting the rule to five IRRs would affect 13%. The minutes do not explain the difference. Perhaps the group revised its sample, counted a different requirement, or simply carried an old figure into the summary. The public record cannot choose among those possibilities. Anyone asking operators to accept a new test should publish the population, rule and method behind each number.

That discrepancy does not make the security problem disappear. It makes the adoption problem measurable. A 13% remediation task and a near-40% membership shock are different decisions. The first may invite a transition schedule; the second could remake the participant list. Both need evidence before they become a rule.

Today’s door has more than one key

The approved Network Operators Actions allow a participant to document intended announcements in the appropriate RIR routing registry, RADB or an RADB-mirrored IRR. They also allow the RPKI route-origin option instead of the IRR route-policy route. RPKI ROAs are currently a recommended action in that document. The working group is debating how much of this flexibility to keep, and whether future compliance should demand RPKI and IRR rather than one of the two. The 8 September minutes ordered a further impact assessment of that conjunction. A three-letter word may decide whether an operator passes.

The same minutes reaffirm a goal of ROAs covering all announcements. The later meeting estimated that this would affect one in five current members. Some missing records are a matter of work; others have an access problem. The 22 September discussion specifically mentions operators in Brazil using TC and BRIRR registrations instead of LACNIC's IRR. The group's charter explicitly includes transition and grandfathering among the adoption questions. A baseline that ignores the path to comply becomes an excellent test of who already has the right paperwork.

MANRS has reason to tighten its language. Its own account of the review says the Network Operators Actions date from 2014, received editorial updates in 2021, and now face their first major review. Better auditability, route filtering and source-address validation are serious work. A participant badge is more useful when the reader can tell which controls it attests. Yet a verifiable standard also needs to state which routes, which customers, which registry records and which evidence count.

A meeting is not a mandate

The group discussed customer connections as the principal scope for filtering; peer relationships remained outside it in the September account. That boundary matters. A requirement framed as protecting customer announcements can sound universal while its actual control surface is narrower. The text should say where a network operator must act and where it is being encouraged to act. Implementation details can live in a guide; pass-or-fail obligations belong where participants can see them.

The MANRS Development Process puts several gates between a working-group preference and a binding participant rule: an internal last call of at least two weeks, community comments for at least four weeks, a two-week participant last call, and Steering Committee ratification. Major decisions must be documented on a mailing list. The proposal listing still describes this review as under discussion. A meeting minute is valuable evidence of the argument, not a new version of the standard.

Sources