Summary
- An external archive of the 7 July announcement says proposal 2026-01 would remove the needs assessment for the first ASN requested by holders of address space assigned or allocated directly by the RIPE NCC; feedback was requested by 5 August.
- The archived discussion shows the proponents willing to retain documented routing policy and acknowledging a controlled-entity route to multiple nominally first ASNs.
- The reviewed evidence contains no later decision or revised text. Before any implementation can be judged, the next record should close three gaps: applicant eligibility, routing-policy documentation and aggregated monitoring with a correction path.
The proposal removes a declaration, not every condition
The launch note is narrower than the headline shorthand first ASN without justification. It applies to a legitimate holder of an IP prefix assigned or allocated directly by the RIPE NCC. It does not say that any person can request an ASN, that every sponsored holder is included or that additional ASNs become automatic.
That boundary matters because the proposal responds to a real design tension. RFC 1930 treats an autonomous system as the unit of a distinct external routing policy. Its 1996 examples say a single-homed site ordinarily does not need a separate AS, while multihoming is the principal case. The July discussion, however, contains support for ending declarations of fictional multihoming made to satisfy the administrative form.
Four-octet support changes the scarcity calculation but not the meaning of a route. RFC 6793 expanded the numerical space from 16-bit to 32-bit ASNs and expressly left allocation policy untouched. That larger identifier space does not prove how many first-ASN requests are false, rejected, routed or operationally useful.
The defensible case for simplification is therefore administrative and evidentiary: if a test routinely produces invented facts rather than discriminating decisions, remove or redesign it. But the case should be measured, not assumed. The sources reviewed here provide no rejection rate and no count of fictional declarations.
Record one: who is receiving a first ASN?
The eligibility phrase combines at least four facts: the applicant's legal identity, control of the address prefix, the relationship by which the prefix was assigned or allocated, and whether this is the applicant's first ASN. Each can be true while another is uncertain.
A public implementation ledger need not expose contracts or personal records. It can publish grouped fields: direct allocation or assignment; sponsoring route if applicable; applicant already holds an ASN—yes or no; related-entity review invoked—yes or no; approved, held, corrected, refused or withdrawn. The private case file proves identity and authority. The public aggregate proves that the boundary is being applied consistently.
This is also where the discussion identified a possible route around the word first. An entity controlling several legal entities might seek one first ASN through each. The proponents said that risk already exists, differs mainly in administrative friction and should be noticed and reported by the RIPE NCC. That is an honest acknowledgement. It is not yet a monitoring design.
Record two: what routing policy survives the simplification?
Several participants separated needs justification from documentation. A network may no longer need to persuade the registry that it deserves an identifier, yet operators and counterparties still need to know what external routing policy the ASN represents.
The archived exchange records a request to retain a documented routing policy and the proponents' willingness to adjust the text. But the evidence packet contains the launch version, not a later published redline. The next document must therefore show the exact answer: what is mandatory for the first ASN, in what format, at what time, and who corrects a record that no longer describes the operating network.
This distinction avoids two opposite errors. Keeping the old multihoming fiction under a different label would defeat the simplification. Removing every structured routing statement would confuse relief from a gate with relief from operating accountability. RPSL may itself be debated, but that debate should be visible in the text rather than settled through case-by-case expectations.
Record three: what would trigger review?
The registry will notice is not yet an observable control. A monitoring note needs a denominator and a clock. How many first ASNs were assigned during a quarter? How many applicants already had a related entity with an ASN? How many records acquired a visible route, remained unannounced or needed correction after a defined interval? Which pattern triggers review of the rule rather than suspicion of an applicant?
Those questions do not imply wrongdoing. An ASN can be legitimately prepared before it becomes visible in public routing, and corporate groups can have distinct networks. The purpose of grouped reporting is to distinguish a predicted consequence from an anecdote. It also prevents one unusual case from becoming a secret amendment to policy.
The monitoring owner should be named before implementation, along with the first publication date, privacy threshold, review trigger and correction procedure. Otherwise the community will receive either silence or an unstructured story after the fact.
The next version should be a decision table
The reviewed record does not establish that proposal 2026-01 was accepted, rejected or implemented after the 5 August feedback deadline. It does establish that the original announcement and the discussion are no longer identical: the proponents accepted the need to add routing-policy documentation, and the debate exposed a related-entity monitoring question.
A useful next version would publish a before-and-after table with five rows: first-ASN eligibility; multihoming declaration; routing-policy record; additional-ASN test; implementation reporting. Every row should identify the decision-maker, evidence, outcome and correction route. An impact analysis can then forecast volume and operating cost against explicit fields rather than against the vague word simplification.
That approach follows Heng Lu's boundary between participation and authority. The mailing list supplies technical evidence, objections and proposed repairs. It does not turn a discussion into adopted policy or relieve the operator of producing an inspectable implementation record.
Sources
- External archive: announcement of proposal 2026-01 and the 5 August feedback deadline
- External archive: consolidated discussion on routing-policy documentation and controlled entities
- RFC 1930, Guidelines for creation, selection, and registration of an Autonomous System
- RFC 6793, BGP Support for Four-Octet Autonomous System (AS) Number Space
- Heng Lu, The Multi-Stakeholder Mirage
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
