The SOURCE Attribute That Became an IRR Trust Label

Summary

RPSL defines source: as the registry where an entity is registered. The attribute identifies provenance; it does not, by syntax alone, certify the current resource holder, authenticate the origin AS, prove freshness or promise that a mirror is current.
Distributed IRRs forced consumers to choose where to query. Direct customer relationships could specify a preferred registry, but third parties often lacked a referral to the authoritative source. Registry names therefore became practical proxies for trust.
Software makes that trust operational. RADb and IRRd allow source selection and ordering; bgpq4 can limit filter generation to named sources; IRRd can assign source-level route-object preferences. A configuration choice can suppress one declaration and admit another before a human sees either.
Brand-based preference is not irrational. RIR-integrated IRRs can authenticate against number-resource records, while some independent databases accept broader communities and preserve useful coverage. The error is assuming that every entity under one label has identical authority, age and maintenance history.
Source quality should be measured in separate dimensions: address-holder authorisation, origin-AS participation, credential strength, freshness, RPKI consistency, BGP relevance, mirror integrity, correction rights, deletion performance, availability and transparency about exceptions.
A source grade should never replace entity-level evidence. A current RPKI-valid route object in a well-controlled source differs from an old NotFound entity under an abandoned maintainer, even when both end with the same source: value.
Operators need reproducible source policy: named sources and versions, conflict rules, reasons for preference, review dates, fail-open or fail-closed behaviour, filter deltas and emergency exceptions. Customers need notice and a remedy when a source-policy change affects reachability.
A Number Resource Society can publish tests and portable evidence profiles for registries and filter providers, but it should not turn accreditation into another permanent brand hierarchy. Trust must expire, be retested and remain contestable.

The most consequential line is often the least descriptive

An RPSL route object can contain a prefix, an origin AS, maintainers, contacts, remarks and timestamps. The line at the bottom may be only source: RIPE, source: APNIC, source: ARIN or source: RADB. It appears modest. In a distributed routing registry, however, that name can decide whether an operator considers the entity, which copy wins a conflict and whether the resulting prefix enters a router filter.

This power is not inherent in the text. RFC 2622 gives the attribute a narrow meaning: it specifies the registry where the entity is registered. The field says where the assertion belongs. It does not say that the assertion is correct, that the address holder approved it, that the origin AS still uses it or that a particular transit network should trust it. Those judgments enter through registry rules and operator configuration.

The distinction matters because identical-looking route objects can have different evidentiary histories. One may have been created through an RIR account tied to the current registered holder. Another may have been proxy-registered years earlier by a provider. A third may be a faithful mirror of the first. A fourth may share the same prefix and origin but have been independently accepted by a database with weaker admission controls. The source: values distinguish publication provenance, but they do not expose all the proof behind acceptance.

Operators nevertheless need a decision. A filter generator cannot debate institutional theory each time it expands an AS-SET. It queries sources, resolves or combines results and emits configuration. In that environment a source name becomes compressed policy: "use these registries," "prefer these registries," or "ignore that registry." The compression is operationally efficient. It is also easy to mistake for a universal trust ranking.

The governing challenge is not to abolish source preference. It is to make the reasons visible, measurable and revisable. A registry name can be a useful starting signal. It should not be a hereditary title that excuses poor authorisation, stale data or weak remedies.

Provenance was necessary because the registry was distributed

The early routing registry was designed for Internet-wide coordination without requiring one organisation to hold every policy statement. RFC 1786 described route objects in the RIPE database in 1995. RPSL generalised the language. By 2000, RFC 2901 described several registries serving different customer bases and advised a network to register routes in one routing database, logically the closest appropriate IRR, even as provider practices varied.

A distributed system needs namespace and provenance. If entities are mirrored into one query service, the consumer must know which source accepted each one. The source name prevents a mirrored RIPE entity from masquerading as a local RADb assertion and allows a client to request selected registries. It also permits two entities with otherwise matching content to retain distinct institutional origins.

Distribution offered practical benefits. Networks could register with a regional or provider community that understood their resources. Mirrors could improve availability and provide one endpoint for broad searches. Different institutions could innovate in interfaces and policy. No global change-control body had to approve each route declaration.

The cost was an authority-discovery problem. RFC 7682 observed that, given a prefix, a third party often could not determine in advance which IRR contained the authoritative, most current statement. A direct provider could ask its customer on a BGP order form. A route server, researcher or distant peer lacked that relationship. Mirroring every known source returned more data but did not explain which assertion deserved precedence.

The source attribute was therefore asked to answer a question larger than provenance: whose institutional process should the consumer believe? RIR names appeared attractive because the same organisation held the number-registration relationship. Provider and independent IRRs remained attractive because they covered customers, legacy arrangements or policy entities absent elsewhere. Source choice became a way to manage incomplete authority.

That evolution was understandable. It was not a formal certification system. A source name describes the institution that admitted an entity; trust depends on what that institution actually checked, how consistently it checked, and what happened after the original check.

Registration location and authoritative evidence are different claims

The word "source" invites over-reading. In ordinary language a source may be the origin of knowledge. In RPSL it is the registry location attached to the entity. The database might be authoritative for the relevant address space, authoritative only for its own local entity collection, or merely willing to publish a customer's statement. Those are different forms of authority.

An RIR-integrated IRR can tie route creation to address and ASN records under its administration. APNIC says its routing registry checks that address ranges and AS numbers fall within APNIC resource ranges and uses maintainer attributes in the resource records to control routing entities. ARIN describes its NRTM source as containing authorised entities tied to a valid maintaining organisation and covered resources. The RIPE Database requires address-space authorisation for route creation within the RIPE region and offers hierarchy-based recovery for certain blocking entities.

Those controls justify evidentiary weight. They do not make every detail timeless. A valid holder can enter the wrong origin. A proxy can be properly authorised and later become obsolete. An entity created under an older interface may have a different maintenance history from one created today. Contacts can decay. A route can remain in the database after service ends. Authority at admission is not an automatic warranty of continuing intent.

An independent registry occupies a different position. RADb can accept and serve routing policy for networks beyond one RIR's direct membership system and offers a combined query view with mirrored registries. That breadth has genuine operational value, especially where the appropriate RIR IRR lacks an entity, where a provider manages policy for customers, or where existing tools expect one broad endpoint. It also means the consumer must ask which submissions were tied to which resource evidence.

The label alone does not provide that answer. source: RADB says RADb registered the entity. It does not say whether the entity was created directly by the holder, by a service provider, through a legacy maintainer or under a current RPKI comparison. source: ARIN carries stronger regional registration integration, but a consumer still needs entity age, status and conflict evidence. Trust attaches to a verifiable act, not typography.

The correct hierarchy begins with claim-specific authority. For an address-origin assertion, current certified address authority deserves particular weight. For AS-SET membership, the relevant AS administrator and hierarchical naming controls matter. For mirror freshness, transport serials and timestamps matter. No single source brand is best at every claim simply because it is well known.

Query options quietly became constitutional rules

The source hierarchy is often implemented in a command-line flag. RADb's query interface permits a client to set selected sources and says the default search order follows server configuration. IRRd permits an operator to define default sources, aliases and order. bgpq4, a widely used configuration generator, accepts a -S list and recommends a set built around RPKI and the RIR IRRs. A carrier can encode its trust constitution in a scheduled command that few customers ever see.

This is not a criticism of automation. The purpose of structured routing data is to support repeatable policy. A source list can exclude databases that do not meet an operator's security standard. An explicit order can make results deterministic. Automated refresh can reduce the delay between a holder's update and a functioning route.

But a source option is a policy decision with consequences. Suppose a customer has a valid route object only in RADb and a transit provider changes its generator from all sources to RIR-only sources. The entity has not become false; it has become invisible to that provider's selected evidence. At the next policy rebuild, the prefix may disappear from the allowed list. Conversely, adding a broad source can introduce an old or unauthorised prefix-origin pair into a filter.

Source order can be more subtle than inclusion. A traditional query may return all matching entities while a client takes the first. A tool may union results. A local database can apply suppression before answering. An operator may aggregate generated prefixes, obscuring which entity admitted a more-specific. The same source list can therefore yield different effective policy under different software and options.

Governance requires operators to document the full decision, not merely name a query host. Which sources were selected? In what order? Were mirrors or authoritative endpoints used? Were RPKI-invalid entities suppressed? Were overlapping lower-preference entities hidden? How were AS-SETs expanded? What happened when the result was empty? When was the generated policy deployed?

These questions are equivalent to procedural rights in a public institution. They determine which claims are heard and which are excluded. A trust label becomes legitimate only when the rules around it are inspectable and affected networks can challenge a consequential error.

Route-object preference makes reputation executable

IRRd's route-object preference feature is an unusually clear demonstration of source reputation becoming code. An administrator assigns a numerical preference to each configured source. When route objects overlap, entities from a lower-preference source can be suppressed in favour of entities from a higher-preference source. The source's rank changes what ordinary queries expose.

The mechanism is useful. If an RIR-authoritative source contains current route data, a local IRRd operator may reasonably want to suppress overlapping entities from a less controlled third-party source. The result can reduce ambiguity and prevent an old broad declaration from influencing filters. Preference can be applied consistently across a large dataset rather than through one-off exceptions.

Its limits are equally instructive. IRRd documentation states that overlap can be exact, more specific or less specific, and that origin ASes are not considered by this preference comparison. A higher-preference entity for an overlapping prefix can affect visibility of a lower-preference entity even when their origins differ. A change in one source can alter the visible status of an entity in another. Sources without configured preference can remain visible outside the comparison.

That is not a defect concealed by the software; it is a policy model the administrator must understand. Source preference answers "which institution's overlapping route data takes precedence?" It does not evaluate the entire semantic relationship between two origins. An operator who assumes it performs complete holder-intent reconciliation may hide a legitimate multiorigin or backup declaration.

Preference also imports the quality of the grade. If a high-ranked source suffers stale maintenance, its overlap can suppress a fresher lower-ranked entity. If a source's admission controls improve, its historical entities do not all acquire the new assurance retroactively. If a registry's regional scope changes after a transfer, a previously authoritative label can cease to be authoritative for that prefix.

The feature should therefore be governed like a consequential rule set. Preference values have stated reasons, owners, effective dates and review dates. Changes are previewed against real entity deltas. Unexpected suppression is sampled. Customers can discover whether their entities are hidden and why. Emergency overrides expire. A rank is a current administrative judgment, not a permanent property of the source name.

One label can cover several generations of control

Institutional reputation often assumes internal uniformity that does not exist. Databases evolve. They retire email updates, add account authentication, introduce hierarchical authorisation, migrate old entities, integrate RPKI, tighten regional scope or add holder challenge tools. The source: value may remain stable across these changes.

ARIN's IRR documentation, for example, distinguishes simple and advanced entities and notes migrated entities from an earlier email-template service. Permissions depend partly on how an entity was created. Its authorised NRTM source has strong current ties to registered organisations, but entity provenance still includes interface and migration history. A careful consumer can recognise the source's institutional strength without pretending every row was born through one procedure.

The RIPE source changed boundaries in a visible way. Out-of-region route and aut-num entities that could not be authenticated against RIPE-managed address space were moved to RIPE-NONAUTH, and new out-of-region route creation was stopped. That relabelling was governance in its purest form: the institution withdrew an implication of authority its ordinary RIPE label could no longer support for those resources.

APNIC's integrated registry checks regional resources and permits imported route objects under specified conditions. Its documentation explains that an entity for APNIC-managed address space can name an external ASN and trigger notice even where the requester lacks the ASN-side authorisation. That is a deliberate policy balance between address-holder control and origin-AS awareness. A consumer assessing source: APNIC should understand the check rather than reduce it to "trusted" or "untrusted."

RADb has added stale-entity assessments using BGP, RIR validation, maintainer relationships, age and other data. Yet it explicitly says the stale mark does not change query behaviour. An operator who selects RADb still needs to decide whether and how to use that status. The institutional label does not absorb the entity-level signal.

Good source governance exposes such generations. Entities can carry creation method, last authenticated review, current status and relevant validation results without revealing secret credentials. Consumers can then prefer stronger cohorts within a source. The alternative is reputation averaging: excellent new controls lending authority to every legacy entity, while a handful of legacy failures unfairly discredit current high-quality records.

The brand shortcut is rational until it stops being tested

Network operators cannot perform a forensic investigation for every prefix in a large customer cone. They use brands because institutions develop repeatable behaviour. A registry that authenticates holders, maintains reliable mirrors, responds to challenges and publishes clear rules deserves more trust than one that accepts unverifiable statements and ignores disputes. Reputation is a legitimate scaling mechanism.

The danger is inherited authority. Once an RIR name or established commercial registry is written into standard configurations, the cost of revisiting it rises. Engineers copy a predecessor's source list. Vendor examples become default. A source remains trusted because large operators trust it, and large operators trust it because it has long been on the list. The original evidence for inclusion disappears.

This circularity protects weak performance from market discipline. A source can have delayed updates, unreachable maintainers or opaque deletion rules while retaining its rank. Conversely, a smaller or newer registry can implement strong resource authentication and timely correction yet remain excluded because it lacks brand history. Neither outcome serves routing security.

Reputation must be renewed by observations. How often does the source verify current holder standing for consequential changes? How quickly are accepted updates available to mirrors? How are abandoned maintainers recovered? What share of challenged entities receives a reasoned decision within the published period? How often do route objects conflict with current RPKI, and how are NotFound cases treated? How often does a mirror lose sequence or serve an old snapshot?

Even these measurements require caution. A source serving difficult legacy and multiregional cases may show more disputes than a tightly scoped source. A high RPKI-alignment rate can reflect strong quality or narrow coverage of RPKI adopters. Rapid deletion can be efficient or reckless. Scores need dimensions, denominators and case mix rather than one league table.

The shortcut remains rational when it is auditable: "we prefer this source for these claims because these current controls and results support it." It becomes mythology when the explanation is simply that the source is famous.

Authority, accuracy and freshness should not share one grade

A single trust score hides the nature of evidence. An entity can be authoritative but inaccurate: the current holder authenticated successfully and entered the wrong origin. It can be accurate but weakly authoritative: a third party copied the real prefix-origin pair from BGP without holder consent. It can be both authoritative and accurate at creation but stale after a network move. It can be current at the authoritative source but old at a lagging mirror.

These states call for different remedies. An authoritative mistake should be corrected by the holder and propagated quickly. An unauthorised but accurate copy should not be relied on as holder permission merely because it matches BGP. A stale entity needs succession and retirement. A mirror lag needs transport repair, not a dispute with the entity maintainer.

Source evaluation should therefore publish a vector. Authority asks what relationship allowed the submitter to speak for the prefix and origin. Authentication asks how the institution established the submitter's identity. Accuracy compares the entity's claim with stronger independent evidence. Freshness measures time since meaningful confirmation, not just timestamp modification. Availability measures whether consumers can obtain current data. Remediability measures whether affected holders and maintainers can correct errors through a fair procedure.

The vector should be claim-specific. RPKI can strongly support prefix-origin authority but does not validate every AS-SET membership or import policy. A number registry can establish the current registered holder but may not know a customer's private transit arrangement. BGP can show a route is used but cannot prove permission. A provider contract can show delegation but may be confidential and temporary.

Operators can then state thresholds. Customer ingress filters may require strong address authority or a reviewed contractual exception. Peering discovery may accept broader evidence but mark uncertainty. A route server may combine RPKI validity with selected IRR records for NotFound routes. Research queries may include suppressed and historical entities precisely because they are studying inconsistency rather than generating permission.

This is more work than a gold, silver or bronze badge. It is also more honest. Trust is not one substance. It is a set of reasons for relying on a claim in a particular decision.

Authentication quality has to be measured at the consequential edge

A source can advertise strong account security while leaving the decisive authorisation weak. Multi-factor login establishes that the account user controls a credential. It does not establish that the account represents the current holder of the prefix, that it may name the origin AS, or that an old provider's delegation remains active. The quality test must follow the claim to the resource edge.

RFC 2725 set out a richer model. Authentication identifies who attempts a change; authorisation determines whether that authenticated actor may perform it. Route creation could consult maintainers associated with address space and origin AS, with hierarchical delegation through mnt-routes and related attributes. The design recognised that route authority joins two domains.

Implementations made different choices. The current RIPE model authenticates the address-space side for route creation and notifies an existing origin AS contact rather than requiring origin-AS authentication. APNIC documentation describes controls using address and AS resource entities while also permitting some external-origin cases with notice. ARIN ties authorised route and aut-num entities to the same maintaining organisation for its validated stream. Each choice has operational reasons and a different assurance profile.

Measurement should ask: what proportion of accepted route changes had current address-holder authorisation? When origin-side approval was not required, was the origin contact notified, and could it contest? Were proxy registrations explicitly delegated? Could the current holder reclaim an entity from an abandoned maintainer? Were legacy authentication methods still accepted? Did high-risk recovery receive independent review?

Raw percentages are not enough. The denominator distinguishes new entities, modifications, deletions, migrated records and administrative recovery. A source might have perfect strong authentication for new entries while most queried entities predate that control. Another might deliberately preserve unmodified historical entities but mark their review status. Consumers need both current-entry performance and stock quality.

The best source is not necessarily the one that demands the most signatures. Excessive requirements can prevent legitimate updates and make data stale. Quality lies in correctly assigning authority, making delegation usable, providing notice and enabling recovery. Security that freezes yesterday's operator in place is not trustworthy maintenance.

Freshness is an event question, not an age threshold

Entity age is attractive because it is easy to calculate. A route object last changed ten years ago looks suspicious. Yet stable networks can announce the same prefix from the same ASN for decades. Requiring periodic textual changes would create noise and reward cosmetic updates. A recent timestamp can conceal a copied or incorrectly confirmed assertion.

Meaningful freshness asks whether the claim survived relevant events. Did the registered holder change? Did the resource move between organisations or RIR regions? Did the origin AS change status? Did a ROA appear that conflicts with the entity? Did the maintainer lose all reachable contacts? Did the provider relationship end? Did the source change its admission policy?

A source can monitor these triggers without pretending to know every private arrangement. Registration events within an RIR are strong triggers for its integrated IRR. RPKI conflict is a strong trigger for any route object. Repeated BGP mismatch is a review signal, not a verdict. Failed notices and inactive credentials raise the need for revalidation. Customer termination events can trigger provider-managed cleanup.

The freshness record should therefore distinguish last modified, last authenticated, last corroborated and last event review. An old unchanged entity can remain high confidence if the current holder recently confirmed it through a strong account and no contradictory event exists. A young entity can be downgraded immediately when a valid covering ROA contradicts its origin.

RADb's stale assessment demonstrates the value and limits of composite signals. Direct BGP matches, shared maintainers, observed AS links, RIR status, age and other sources can identify entities worth attention. The badge does not itself suppress the entity, appropriately leaving the operational decision to policy. The next step is to provide an accountable confirmation or retirement route.

Freshness service levels should be stated by event class. A security conflict requires rapid review. A resource transfer should trigger pre- and post-transfer reconciliation. A dormant backup can have a longer confirmation period. One universal expiry date would either delete useful stable policy or tolerate dangerous change for too long.

RPKI is a stronger authority signal, not a universal replacement label

The development of RPKI changed the evidence hierarchy. A relying party can validate that a ROA was issued under a certificate chain covering the address resource. For origin claims, that is stronger than merely knowing which IRR accepted a text entity. Modern IRRd can suppress RPKI-invalid route objects and can create pseudo-IRR objects from validated ROAs so existing tools can consume them.

This has encouraged configurations in which RPKI appears alongside RIR source names. The bgpq4 manual recommends a source list beginning with RPKI and followed by the five RIR IRRs. The ordering communicates a sensible preference for cryptographically grounded origin authority and regionally integrated registration data.

Still, source: RPKI in a generated pseudo-entity is not the same institutional fact as source: RIPE in a submitted RPSL record. The former is a transformed representation of a validated signed entity. The latter is an IRR entry accepted and maintained under database rules. They can express similar prefix-origin information, but their update, scope and failure semantics differ.

RPKI also does not certify every IRR object class. RPSL includes AS sets and richer policy used to generate customer cones and filters. A ROA authorises an origin and length; it does not state the complete transit relationship or guarantee that the route is currently announced. A legitimate holder can make a configuration error. A NotFound route has no covering validated payload and is not thereby unauthorised.

The strongest design uses RPKI as claim-specific evidence. RPKI-invalid route objects face suppression or urgent review, with notice and a correction path. RPKI-valid alignment raises confidence. NotFound entities remain subject to IRR authorisation, freshness and BGP evidence rather than automatic rejection. AS-SETs receive their own hierarchical and membership controls.

This avoids replacing one brand hierarchy with another. Cryptography proves that an authorised key made a narrow statement under a valid chain. It should receive high weight for that statement. It should not be used to imply that every other policy question has been answered.

BGP agreement is useful and dangerously seductive

When no authoritative IRR or ROA settles a conflict, operators often compare route objects with the default-free-zone routing table. A matching prefix and origin appears to confirm reality. Measurement studies use this comparison to classify entities as routed, conflicting or inactive. The method is indispensable for assessing operational relevance.

It is not authority. A hijacked route can match itself. A network can announce through an origin without updating an old holder-controlled record. A legitimate backup entity can have no current global announcement. Private interconnections, regional visibility, aggregation and temporary mitigation can escape selected collectors. BGP describes observed reachability, not consent.

Recent research presented by AMS-IX and DE-CIX researchers and summarised on RIPE Labs found directional differences between RIR-authoritative and third-party IRR data, using RPKI, authoritative IRR records and BGP visibility as quality indicators. The work supports measuring source performance rather than assuming equality. It also makes classification choices: an entity not seen in the default-free zone may be stale, private, backup or otherwise outside the measurement.

Source grades must preserve those caveats. A registry should not improve its score by deleting every entity absent from collectors. An operator should not accept a third-party route object solely because an announcement already exists. Researchers should publish vantage points, collection dates, prefix handling, conflict precedence and exclusions. Counts from one study period are not permanent properties of a brand.

BGP agreement is best used as one axis. Strong authority plus current BGP agreement supports both permission and use. Strong authority without BGP can support prepared or backup policy. Weak authority with BGP agreement requires holder confirmation. Conflict with strong RPKI evidence requires urgent review regardless of BGP visibility.

This matrix is slower to explain than "source X is trusted." It produces better filters because it distinguishes the reason for confidence and the remedy for doubt.

Mirror quality is part of trust even though it is not entity authority

An authoritative source can maintain excellent records while a consumer receives an old mirror. The source: line remains unchanged because the entity's institutional origin has not changed. Nothing in that line reveals whether the local copy is current, whether a journal gap occurred or whether the mirror silently fell back to an older snapshot.

RFC 7682 documented weaknesses in older NRTM replication, including lack of strong validation and synchronisation problems. Modern software offers better controls. IRRd can keep source-specific journals, fetch serial information, apply full imports and NRTM updates, and expose status. RIPE's newer replication design uses source-specific sessions, versioned snapshots and deltas with hashes. These mechanisms make freshness and integrity more observable.

They need to appear in source policy. An operator that says it trusts ARIN but queries a mirror last updated two days ago is not receiving current ARIN evidence. A filter system should record the authoritative source version or serial, mirror fetch time, validation result and age at compilation. If the mirror is unhealthy, the operator decides whether to hold the last known policy, query an alternative endpoint or pause changes.

Failover choices have consequences. Holding an old filter preserves continuity but can retain revoked permission. Rebuilding from an incomplete source set can remove legitimate routes. Failing open can admit unregistered announcements; failing closed can disconnect customers. The appropriate action depends on session type, last-known state, RPKI evidence and incident context.

Availability therefore deserves its own source grade. Measure successful update retrieval, lag distribution, sequence-gap recovery, snapshot integrity, status transparency and time to incident resolution. Do not mix those results with holder authorisation. A registry may be authoritative but temporarily unavailable; a mirror may be highly available while serving weakly authorised data.

This separation creates accountability. Registry operators can improve publication. Mirror operators can improve transport. Filter providers can improve stale-state handling. Customers can know which layer failed. The source label continues to identify provenance without being forced to conceal every downstream condition.

Correction rights are a better signal than prestige

Errors are inevitable in a public operational registry. Trust depends less on claiming perfection than on making error correction effective. A current holder must be able to discover entities covering its resources, authenticate standing, submit evidence and receive a reasoned response. A listed maintainer and origin AS need notice and a chance to explain continuing authority. Consumers need status and safe exceptions while the dispute is reviewed.

RIPE's force-delete mechanism gives current holders a bounded way to remove blocking entities under the authoritative address hierarchy. Its non-authoritative cleanup policy used RPKI conflict, notice and a sustained period before deletion. RADb invites maintainers to review stale classifications and provide BGP or other supporting evidence. These are different remedies shaped by different institutional positions.

The measurable questions are practical. How clear is the challenge route? What proof is accepted? Is the decision-maker independent of the original submitter? Are notices delivered through current resource channels as well as entity contacts? Can an urgent suppression be reviewed quickly? Is historical evidence preserved? Can a mistaken deletion be reversed without pretending it never happened?

Prestigious sources can fail these tests, and less famous sources can pass them. A brand built on technical history does not excuse an unresponsive support queue. Nor should rapid customer service replace due process; a registry that deletes on the request of the loudest network is not trustworthy.

Remedy data should be published in aggregate with defined populations: challenges received, authority classes, outcomes, decision intervals, emergency actions, reversals and unresolved cases. Sensitive identity and commercial evidence can remain protected. Sampled independent audits can test whether published rules were followed.

An operator deciding source preference should weigh this evidence heavily. A wrong entity in a source with credible correction is a bounded risk. A wrong entity in a source with no standing, notice or appeal can become permanent operational permission. Institutional legitimacy is revealed when a claimant says the institution is wrong.

A measurable source profile can replace the folk ranking

A useful profile begins with scope. Which address and AS resources can the registry authenticate directly? Which entities are accepted for out-of-region resources? Which classes are authoritative, mirrored or derived? Which current and legacy submission methods exist? Without scope, high performance in one narrow population can be mistaken for universal quality.

The second section covers admission. It records address-holder authorisation, origin-AS authorisation or notice, delegation controls, credential methods, recovery checks and treatment of proxy registrations. Results distinguish newly created, modified, migrated and untouched legacy entities.

The third covers continuing quality: last authenticated confirmation, event-triggered review, RPKI-valid, Invalid and NotFound handling, BGP comparison, inactive contacts, transfer reconciliation and duplicate detection. It reports each signal separately rather than declaring every mismatch false.

The fourth covers distribution: authoritative publication time, mirror availability, version continuity, lag, integrity validation and status visibility. The fifth covers remedy: discovery, standing, notice, suspension, deletion, appeal, reversal and history. The sixth covers operational use: how selected filter providers include the source, what conflict rules they apply and how customers receive notice of policy changes.

Scores can then be contextual. A carrier might require a high address-authority and remedy grade for customer ingress while accepting moderate BGP coverage. A researcher might value history and broad coverage more than suppression. A route server might prioritise RPKI integration and current AS-SET maintenance. One institution can have different grades for different entity classes.

Measurements must be reproducible. Publish the period, dataset, tests, exclusions, denominators and responsible assessor. Preserve failed and disputed samples. Expire the result. A source that changes software or admission policy receives a new assessment. An accreditation mark links to evidence instead of becoming a timeless logo.

The profile will not remove judgment. It will improve it. Operators can explain why they selected a source. Registries can see which controls need investment. Holders can compare services. New entrants can earn trust through performance rather than waiting decades for a brand.

Operators owe customers a source policy they can inspect

A transit network's filter is private configuration, but the evidence rule that determines customer reachability should not be a secret. At onboarding, the operator should state accepted IRR sources, whether it uses RPKI, required AS-SET conventions, refresh frequency, conflict precedence and emergency update procedure. Customers can then register in the right place and understand how changes reach the edge.

The source policy should be versioned. When the operator removes or demotes a source, it previews the effect on current customers and identifies prefixes that would disappear or change origin permission. Affected customers receive notice and a period to create stronger authoritative records. Security-critical conflicts can still trigger rapid action, but ordinary policy migration should not surprise the people whose routes depend on it.

Generated filters need provenance. For each deployment, retain tool version, query endpoint, selected sources, source versions, suppression settings, AS-SET roots, output hash, reviewed delta and router targets. This evidence allows a network operations centre to answer why a prefix was accepted yesterday and rejected today.

Exceptions need the same discipline. A customer with legitimate legacy space may be unable to meet the default source rule immediately. A manual prefix allowance can preserve service while registration is repaired. The exception records authority evidence, approver, scope and expiry. It does not become an invisible permanent bypass.

Operators should test empty and degraded states. If the preferred RIR source is unreachable, does the system use the last known filter, broaden to all sources or remove customer prefixes? If RPKI data is stale, how are Invalid results treated? If an AS-SET expansion suddenly grows, is deployment paused? Source trust includes the behaviour around failure, not only normal query results.

This transparency does not require publishing customer topology or router credentials. It requires publishing the rule by which institutional evidence becomes permission. A customer paying for transit has a legitimate interest in that rule and a remedy when it is applied incorrectly.

Rankings can be gamed unless the denominator remains visible

Once source quality affects reputation and procurement, institutions will optimise for the metric. That can be beneficial if the metric tracks real authority and correction. It can also produce cosmetic improvement. A registry may exclude difficult legacy entities from its reported population, refresh timestamps in bulk, suppress conflicts rather than resolve them or count unanswered notices as completed reviews.

Each indicator therefore needs a denominator and disposition. RPKI conflict rates specify whether they cover all route objects, only routed entities or only prefixes with covering ROAs. Freshness rates distinguish meaningful holder confirmation from automated modification. Challenge performance includes withdrawn, upheld, rejected, reversed and still-open cases. Mirror availability distinguishes authoritative publication from third-party retrieval.

Case mix must be visible. RIR IRRs can authenticate their own regional resources more directly than a global independent registry. An independent source may carry more legacy, multiregional and proxy records precisely because it fills gaps. Comparing their raw conflict rates without scope would reward narrowness. The profile should assess whether each source applies controls appropriate to the claims it chooses to host.

Suppression must not erase the audit population. If IRRd hides RPKI-invalid or lower-preference entities from ordinary queries, quality reporting should still count them and show why they were suppressed. Otherwise a source can appear clean because problems are invisible. Historical copies should be separated from active policy views but remain available for authorised review and research.

Independent sampling can deter gaming. Assessors select entities across age, authority class and outcome, replay admission and challenge evidence, and compare authoritative and mirrored states. Registries can protect credentials and personal data while proving that checks occurred. Disputed cases should be published in anonymised reason categories.

The objective is not a permanent winner. It is continuous improvement and honest source selection. A ranking that cannot fall becomes brand authority by another route. A measure that exposes its bounds can support trust without pretending to abolish uncertainty.

Institutional legitimacy comes from constrained power over visibility

Source preference controls visibility. A registry decides what it accepts and removes. A mirror decides which sources it carries. A filter operator decides which labels it trusts. IRRd can suppress overlapping lower-preference entities. Together these choices can make a network's declaration operationally legible or practically absent.

Such power needs constraints even when exercised by private technical organisations. Rules are published in advance. Decisions use relevant evidence. Similar cases receive similar treatment. Affected holders and maintainers receive notice. Emergency action is narrow and reviewed. Reasons can be inspected. Errors can be corrected. Metrics reveal exceptions.

Institutional brand can support legitimacy only as a summary of this behaviour. An RIR's role in number registration gives it a special evidentiary position, but not an exemption from fair correction. A commercial registry's broad service can create valuable coverage, but customer payment does not establish resource authority by itself. An open-source implementation can make policy transparent, but the local administrator still chooses the configuration.

The source attribute should remain stable provenance. Rewriting it merely to confer prestige can mislead consumers about where and under what rules an entity was registered. RIPE's creation of RIPE-NONAUTH was defensible because it explicitly distinguished a collection for which ordinary regional authority did not apply. Any similar relabelling should preserve history and notify maintainers.

Consumers should be able to see both origin and treatment: original source, authoritative or mirrored status, validation states, local preference, suppression reason and observation time. This keeps the database's act separate from the filter operator's judgment. It also makes disagreement possible without corrupting the entity.

Legitimacy is not achieved when everyone uses the same ranking. It is achieved when different operators can make evidence-based choices, explain them to affected networks and revise them when performance changes.

Number Resource Society can test trust without minting another badge of faith

NRS presents accurate number registration, operator rights and institutional accountability as central concerns. Those aims fit a source-quality programme if the programme remains technical, bounded and plural. NRS could define an open profile for IRR authorities, mirrors and filter providers and commission repeatable conformance tests.

For registries, tests would examine resource-holder authorisation, origin notice, delegated maintenance, legacy-entity marking, event-triggered review, challenge standing, reversible suppression, deletion evidence and publication status. For mirrors, they would examine source fidelity, version continuity, lag and incident reporting. For filter providers, they would examine explicit source selection, conflict handling, reproducible generation, customer notice and exception expiry.

Results should be evidence records, not endorsements of every entity. A registry can pass an admission test while one holder makes a mistake. A mirror can pass integrity tests while its source contains stale policy. A provider can implement its stated source rule correctly while the rule remains open to challenge. Scope and limitations travel with the result.

Accreditation must expire. The tested software version, policy version, period and sample are visible. Material changes trigger reassessment. Complaints can open a focused review. NRS members and non-members receive the same technical criteria. No source receives permanent higher rank because it helped design the test.

NRS should not become the universal IRR, choose every operator's filter or claim legal authority over number resources. Its own public statements are advocacy evidence, not proof that a source-quality system already operates. A constructive role is to make institutional claims comparable and to help holders exercise correction rights across fragmented services.

This is a positive form of decentralisation. RIRs retain their resource-registration responsibilities. Independent registries retain their service models. Operators retain routing policy. A common evidence profile lets trust move when performance moves, rather than remaining attached to whichever names dominated configuration files in an earlier era.

The source field should return to provenance and trust should show its work

The source attribute has done its original job well. In a mirrored, distributed registry, it tells the reader where an entity was registered. Problems begin when that small piece of provenance is treated as a complete certificate of authority, freshness and operational fitness.

Operators will continue to prefer some sources. They should. A source integrated with current number registration and strong holder authentication normally deserves more weight for prefix authority than an unauthenticated third-party statement. A source with reliable publication and correction deserves more operational confidence than one with opaque delays. These are evidence-based distinctions, not an argument that every database is equal.

The distinction must remain conditional. Trust is attached to a claim, an entity cohort, a current policy and measured service. It can rise when authentication improves and old entities are reviewed. It can fall when mirrors lag, challenges go unanswered or institutional scope no longer matches the resource. It can differ for route objects and AS sets. It can be overridden by stronger entity-level evidence.

A mature filter record should be able to say: this prefix entered because a current holder-controlled assertion in a named source passed stated checks at a stated version; this conflicting entity was excluded for a documented reason; this mirror was current; this customer was notified; this exception expires. That explanation is longer than a source name and far more useful after an outage or dispute.

From 1995 onward, routing registries converted social trust among network operators into structured declarations. The source label preserved the institutional location of those declarations. Three decades of automation turned location into rank. The next step is not to abandon reputation but to discipline it.

Source names should identify where claims came from. Trust grades should identify why claims deserve reliance now. When the two are separated, brands can still earn confidence, smaller institutions can prove quality, legacy records can be treated according to their actual evidence, and operators can defend the policies they deploy. Authority then becomes measurable performance rather than inherited lettering at the bottom of an entity.