Summary

  • Urban Suhadolnik and Tobias Fiebig co-authored RIPE proposal 2025-01. The proposal was published on 6 May 2025, revised to version 2.0 on 16 October 2025, withdrawn on 6 July 2026, and never adopted as policy. [2] [3]
  • At RIPE 91, Urban answered recorded questions about fees, business-unit edge cases and intermittent research use, and described another revision step. That record supports a personal role in policy iteration, not sole authorship, consensus or implementation. [3]
  • Urban and Leo Vegoda then co-authored proposal 2026-01, published on 7 July 2026. It remains open for discussion and therefore must not be described as current operative policy or as an outcome already delivered. [1]
  • The newer text would remove needs justification only for the first autonomous system number requested by a legitimate holder of RIPE NCC-assigned or allocated address space. It would retain unique-routing-policy, multihoming and in-use requirements for additional ASNs. [1]
  • The durable issue is not whether a registry should simply say yes or no. It is whether its records and eligibility tests preserve uniqueness, accountability and operational continuity without requiring applicants to stage a network design merely to satisfy an administrative formula.

A policy record, not a victory announcement

The safest way to understand Urban Suhadolnik's contribution is to begin with status. Proposal 2025-01 is a withdrawn proposal. Proposal 2026-01 is a current proposal under discussion. Neither statement is a semantic technicality. They determine what a reader may reasonably infer about the networks, organisations and people affected by the text.

When a proposal is withdrawn, it has not silently become policy. Its language may have influenced later drafting, and the discussion may have clarified a problem, but operators remain governed by the rules that are actually in force. Likewise, a proposal open for discussion is not a promise that a registry will accept future requests under its suggested test. It is an invitation to scrutinise the proposed test before the community decides whether and how it should change the policy record.

The two RIPE pages establish those statuses directly: 2025-01 was withdrawn on 6 July 2026, while 2026-01 was published on 7 July 2026 and is open for discussion. [1] [2]

This sequence matters because policy stories are often compressed into a simple arc: somebody identifies friction, publishes a proposal and “changes the rules.” The documentary record supports a more disciplined account. Urban co-authored the earlier proposal with Tobias Fiebig. He participated in the recorded discussion and responded to concrete questions. The earlier proposal was withdrawn. Urban then co-authored a narrower successor with Leo Vegoda. The successor remains subject to discussion.

Credit belongs to the named contributors, but authority remains distributed across the working group, the policy-development process and the community's eventual judgment.

That distinction is particularly important for number resources. An autonomous system number, or ASN, is a unique identifier used in interdomain routing. Networks use ASNs to express routing relationships and exchange reachability information through the Border Gateway Protocol. An ASN is therefore not a decorative badge and not proof that an organisation is large, independent or successful. It is a record that helps distinguish one routing policy from another in the shared Internet routing system.

The RIPE NCC is the regional Internet registry serving Europe, the Middle East and parts of Central Asia. In this role it maintains number-resource records and administers policy developed through the RIPE community. The registry does not manufacture the operational need that causes a network to announce routes, connect to upstream providers or establish a distinct routing policy. Nor does a policy document by itself cause those actions. The record and the network have to agree closely enough that other participants can identify responsibility, diagnose failures and understand which routing decisions belong together.

What “first ASN” means in practice

The phrase “first ASN” sounds simple, but it describes a boundary between two different administrative questions. The first is whether a legitimate holder of RIPE NCC-assigned or allocated IP address space should have to justify its initial ASN through a prescribed network design. The second is whether an organisation requesting additional ASNs should demonstrate that those identifiers will represent distinct routing policies and real use.

Proposal 2026-01 separates those questions. As documented in the current text, a legitimate prefix holder requesting its first ASN would not have to provide the same needs justification. A prefix holder in this context is an organisation with address space assigned or allocated through the RIPE NCC system. The proposal does not say that anybody may request unlimited identifiers. For additional ASNs, it retains requirements tied to unique routing policy, multihoming and use. [1]

Multihoming generally means connecting a network through more than one external path or provider. It can support continuity, traffic engineering or administrative independence, but the word alone does not prove that any particular design is resilient. A network can have two nominal connections that share an underlying failure point, and a single connection may serve a deliberately limited purpose. A unique routing policy means that an ASN represents routing decisions meaningfully distinct from those represented by another ASN. The test is about operational separation, not merely paperwork or organisational charts.

The earlier proposal tried to address the same broad source of friction but followed a wider route. Its record, including the version history and the discussion at RIPE 91, provides the baseline from which the narrower successor can be understood. The 2025 text was first published on 6 May 2025 and revised to version 2.0 on 16 October 2025. The meeting minutes describe questions about cost, organisational edge cases and intermittent research activity, as well as Urban's answers and an intention to revise the text again. [2] [3]

Those questions reveal why a first-ASN rule is not merely a contest between strictness and convenience. A policy must work across organisations whose networks are arranged differently. A business unit may operate under a larger legal entity while needing its own routing control. A research network may use a resource intermittently rather than continuously. A small prefix holder may need a distinct routing identity without having a textbook multihoming arrangement at the moment it applies. At the same time, a registry needs a defensible reason not to issue multiple identifiers that merely duplicate one routing policy or remain unused.

The 2026 proposal's narrower structure can be read as an attempt to place scrutiny where it is most informative. For a qualified holder's first ASN, the existence of address space and the need to participate in routing may provide a sufficiently bounded entry point. For additional ASNs, the applicant would still need to show distinct routing purpose and use. That is not a conclusion that the proposed wording is correct. It is an explanation of the mechanism the authors placed before the community.

Urban's role in the revision chain

Urban's person-level contribution is clearest where the record names an action. The proposal pages name him as a co-author. The RIPE 91 minutes record his answers during discussion of 2025-01 and his description of a next revision. These are dated, attributable acts: drafting with another author, presenting or discussing the text, responding to operational objections and participating in revision. [1] [2] [3]

The evidence does not support a larger claim that Urban individually controlled the process or delivered an implementation result. Tobias Fiebig shares authorship of 2025-01. Leo Vegoda shares authorship of 2026-01. Questions and comments from other participants influenced the discussion. The working group process determines whether consensus exists. The RIPE NCC records and applies policy once the process produces an adopted result. Keeping these roles separate is not an exercise in minimising contribution; it is the method by which contribution becomes credible.

The official RIPE 89 biography provides limited context around Urban's interests in network security, IPv6 and Internet measurement. That context helps explain why number-resource policy and routing questions are within his public technical orbit. It does not prove the proposal work on its own, and it does not establish a current employer, a deployment scale or a measured network outcome. The proposal pages and minutes provide the contribution evidence; the biography helps close identity and work-context questions. [6]

This attribution boundary also improves the article's practical value. If a reader treats policy as the achievement of one person, the reader may miss the mechanism that matters: drafts are tested against operator cases, objections expose ambiguous language, revisions narrow or clarify the rule, and the community evaluates whether the updated text can be administered consistently. Urban's contribution belongs inside that mechanism, where it can be evaluated from the record rather than inflated into a profile of influence.

The withdrawal of 2025-01 is not evidence that the work was pointless. Withdrawal can mean that a proposal did not secure consensus, that its framing needed substantial change or that a different text became a better vehicle for the underlying issue. The external ARIN meeting transcript described the earlier proposal as an effort to revise and simplify ASN eligibility, noted that it had not met consensus in RIPE and reported an intention to produce a new version. That is useful corroboration of status and significance from outside the immediate RIPE proposal page.

It does not independently identify Urban, and it does not turn the successor into an adopted result. [4]

The operator explainer from Virtua.Cloud provides another bounded perspective. At its stated March 2026 status point, it explained the operational multihoming requirement, discussed the proposed change and warned that 2025-01 had not passed, so the existing requirement still applied. The source helps show what an operator could and could not rely on while the debate continued. It is not proof of consensus, implementation or Urban's identity. [5]

Why administrative friction can distort operating evidence

Eligibility rules are meant to protect a shared resource system, but every test also changes applicant behaviour. If a rule asks for multihoming as evidence of a need for a first ASN, a qualified operator may have an incentive to arrange or describe connectivity primarily to fit the test. That does not mean the connection is fake. It means the administrative criterion may become a design constraint even when the more relevant question is whether the operator legitimately controls address space and needs a distinct routing identity.

This is the strongest operational argument for separating the first request from later requests. A first ASN establishes an initial routing identity. An additional ASN raises a different question: why should one operator or organisational group need another identifier, and what distinct routing policy will it represent? A uniform test can look consistent while obscuring that difference.

Administrative simplicity is not automatically operational truth. Removing a justification field can reduce paperwork without improving record quality if the remaining identity and resource checks are weak. Conversely, a demanding diagram or provider letter can make a file look complete while saying little about whether the ASN will be used accurately. A good rule asks for evidence that corresponds to the decision being made.

For the first ASN, address-space legitimacy can serve as one anchor. The prefix relationship connects the applicant to a recognised resource record. It narrows the class of eligible applicants and gives the registry a basis for accountability. For additional ASNs, evidence of unique routing policy and actual use can serve as a second anchor. The goal is not to approve more or fewer requests in the abstract. The goal is to make the identifier record correspond to distinct operational control.

The proposed compromise still leaves questions. A prefix holder may control address space but lack the competence or arrangements needed to operate a stable autonomous system. A statement of unique routing policy may be difficult to verify before deployment. Multihoming can be described in formally correct but operationally shallow ways. “In use” can mean different things depending on timing, research activity and phased rollout. Policy language must be clear enough for staff to administer consistently without pretending that paperwork can predict every routing outcome.

Those uncertainties are reasons for scrutiny, not arguments for keeping every historic criterion. A registry is a recordkeeper and administrator. It should preserve uniqueness, accurate attribution, security metadata and continuity. It should not treat an inherited form as legitimate merely because it is familiar. If the old test encourages applicants to optimise for the form rather than the network, the test deserves review.

Consensus is a control, not a synonym for popularity

The current proposal is open for discussion, and that status places responsibility on both supporters and critics. In RIPE policy development, consensus is not a simple vote count or the volume of positive comments. It requires addressing material objections and determining whether unresolved concerns prevent the community from accepting the change. The exact process belongs to the RIPE community, but the practical meaning for readers is straightforward: discussion does not equal adoption.

This control matters because number-resource policy has distributed effects. A rule may reduce cost for applicants while increasing verification work for registry staff. It may simplify initial access while creating new incentives for speculative requests. It may improve clarity for small operators while introducing edge cases for research networks or complex corporate groups. The community needs enough information to judge those trade-offs, and the text needs to be precise enough to be applied repeatedly.

Urban's recorded answers at RIPE 91 are valuable in this context because they expose the work between publishing and adoption. Questions about fees, business units and intermittent use require the authors to translate a principle into cases. A proposal becomes more credible when its authors can state what it covers, acknowledge what it does not resolve and revise language that would produce inconsistent decisions. The minutes document participation in that work; they do not predetermine the community's answer. [3]

The move from the broader 2025 proposal to the narrower 2026 proposal also suggests a useful drafting discipline: reduce the number of things a single change tries to settle. A first-ASN exception can be evaluated separately from the controls on additional ASNs. Keeping those controls can reassure participants that the proposal is not an invitation to accumulate identifiers without distinct routing purpose. Narrowing does not guarantee consensus, but it can make the disagreement more testable.

What operators should and should not infer

An operator reading about 2026-01 should not change an application on the assumption that the proposed rule is already active. The current page says the proposal is open for discussion. Until the policy process produces an adopted text and the registry announces the operative procedure, the existing requirements remain the practical reference. External material from ARIN and Virtua.Cloud reinforces the non-adoption status of the earlier proposal at the dates those sources describe. [1] [4] [5]

Operators can still learn from the debate. First, they can distinguish the operational need for an ASN from the evidence a form currently requests. Second, they can document address-space control, routing intent, upstream relationships and intended use in a way that remains useful even if the specific eligibility test changes. Third, they can identify whether multiple ASNs would represent genuinely different routing policies rather than internal accounting boundaries.

The distinction between routing identity and corporate identity is especially important. A legal organisation may contain several networks with different routing controls, or several legal entities may rely on one routing policy. Neither the corporate chart nor the number of contracts alone determines how many ASNs are operationally justified. The policy needs a recordable test that registry staff can apply while operators retain responsibility for what they actually announce.

Small and research-oriented networks may experience the highest relative cost from a poorly aligned test. Preparing extra provider arrangements, explanatory letters or diagrams can consume significant time even when the applicant already holds legitimate address space and has a bounded routing purpose. Yet lowering friction must not erase accountability. Accurate contact data, secure account controls, resource linkage and a clear responsible party remain essential regardless of the multihoming test.

Large organisations face a different problem. If the first-ASN path becomes simpler, internal groups may try to use it as a shortcut for multiple routing identities. The proposal's preservation of additional-ASN tests is therefore not a minor footnote. It is the part of the mechanism designed to keep the first-request exception from becoming a general exemption.

The registry as a reality layer

The enduring principle is that registry records should describe operational reality closely enough to support coordination. They are not sovereign permission slips that create legitimate routing through administrative declaration. They are also not optional clerical notes. Unique identifiers, accurate holders, security metadata and dependable transfer or assignment records reduce ambiguity when networks interconnect and when incidents occur.

A first-ASN policy should therefore be judged by the quality of the reality it records. Does it identify a legitimate resource holder? Does it preserve a unique identifier? Does it create a clear accountable relationship? Does it avoid forcing an applicant to manufacture a network arrangement that is irrelevant to the identifier? Does it retain meaningful controls when the same party asks for additional identifiers?

Proposal 2026-01 offers one answer: use legitimate RIPE NCC address space as the bounded basis for the first ASN, then retain unique-routing-policy, multihoming and in-use tests for additional requests. The community may accept, amend or reject that answer. The proposal's value at this stage is that the answer is explicit enough to examine.

Running networks remain the final reality check. An assigned ASN does not guarantee correct route announcements, secure routing practices, diverse connectivity or effective incident response. Those outcomes depend on configuration, monitoring, upstream coordination and continuing stewardship. Policy can make accurate participation easier or harder, but it cannot substitute for operations.

That limitation should shape public language about the proposal. It is reasonable to say the newer text aims to reduce an administrative barrier. It is not reasonable to claim that the change has improved resilience, competition or deployment, because it has not been adopted and no such measured outcome is in the evidence. It is reasonable to say the retained controls address additional-ASN accountability. It is not reasonable to guarantee that every future application would represent a truly distinct routing policy.

A disciplined conclusion from an unfinished process

Urban Suhadolnik's documented contribution is the work of policy iteration. He co-authored the withdrawn 2025 proposal, responded to operational questions in a recorded working-group meeting and co-authored the narrower 2026 proposal. The record supports each of those acts while keeping his co-authors, community participants and the registry process visible.

The sequence is more instructive than a hero narrative. The broader text created a debate. The debate surfaced cases and objections. The earlier proposal was withdrawn. A narrower successor separated the first-ASN question from additional-ASN controls. The successor is still being tested in public discussion. That is how a shared operational rule should be treated: as a claim about reality that must survive evidence and objections before it is written into the ledger.

For operators, the immediate rule is caution. Do not confuse a proposal page with an implemented procedure. Continue to follow the policy in force, document real routing needs and watch the status of 2026-01. For the community, the question is narrower and harder: can the first-ASN test be simplified without weakening the accuracy, uniqueness and accountability that make autonomous system numbers useful?

The answer cannot be inferred from authorship, reputation or attendance. It will depend on the text, the objections it resolves and the evidence that its distinction between first and additional ASNs can be administered consistently. Urban's contribution is meaningful because it is visible inside that process, not because the process has already produced the result.

Simplicity should expose evidence, not erase it

There is a difference between simplifying an eligibility rule and declaring the underlying resource abundant or consequence-free. The newer proposal addresses the justification path for a first ASN; it does not change the requirement that the identifier be unique or the fact that routing actions become visible to other networks. A simpler admission test can therefore coexist with stricter expectations for account security, contact accuracy, route authorisation and continuing use.

This distinction helps resolve a common false choice. Critics do not have to defend every inherited form in order to defend stewardship. Supporters do not have to dismiss misuse risks in order to question a multihoming prerequisite. Both sides can ask which evidence belongs at which stage. Identity and prefix control can be tested before assignment. Distinct routing policy can be tested for additional requests. Actual use and continuing accuracy can be monitored after assignment. Each control has a different purpose.

The public record does not yet show whether the community accepts this allocation of controls. That uncertainty is material. It is also productive: the proposal is specific enough that participants can challenge the qualification boundary, the handling of legacy resources, the definition of additional use and the evidence staff would need. A testable disagreement is more valuable than a broad promise to make ASN assignment either easier or safer.

Sources

  1. RIPE NCC, “Simplify assignment of first ASN”, proposal 2026-01: https://www.ripe.net/community/policies/proposals/2026-01/
  2. RIPE NCC, “Revised Autonomous System (AS) Number assignment criteria”, proposal 2025-01: https://www.ripe.net/community/policies/proposals/2025-01/
  3. RIPE Address Policy Working Group, RIPE 91 meeting minutes: https://www.ripe.net/community/wg/active-wg/ap/minutes/ripe-91-address-policy-working-group-minutes/
  4. ARIN 57, day-one transcript and regional policy update: https://www.arin.net/participate/meetings/ARIN57/day1_transcript/
  5. Virtua.Cloud, operator explainer on registering an ASN in the RIPE NCC region: https://www.virtua.cloud/learn/zh/concepts/ru-he-zai-ripe-ncc-zhu-ce-asn
  6. RIPE 89 Programme Committee candidate biographies: https://ripe89.ripe.net/programme/ripe-pc/candidate-biographies/
  7. RIPE NCC copyright statement: https://www.ripe.net/about-us/legal/copyright-statement/