Summary

  • PeeringDB’s record for AFRINIC ASN 33764 currently exposes AS-AFRINIC without a source qualifier, while the product’s 2026 change is meant to make ambiguous IRR references easier to resolve.
  • A qualifier can identify where a set name should be looked up. It cannot establish the set’s membership, authorization, freshness or suitability for a live routing filter.

A field can be a pointer without being proof

PeeringDB’s AFRINIC network record, ID 3803, lists ASN 33764 and the IRR AS-SET AS-AFRINIC. The public API returns the same value in its scalar irr_as_set field. The page also displays “IRR AS-SET Verified”. That is a useful record of what PeeringDB presents; it is not, on the evidence reviewed here, a visible audit trail of which IRR was queried, when the query ran, what authorization was tested or which members were returned.

The dates need the same care. The API’s top-level network record says it was updated on 2 May 2025, while its peering LAN data has a separate netixlan_updated date of 26 March 2026. The later child-record timestamp is not evidence that the AS-SET field itself changed then. Nor does the earlier top-level date establish that the whole network record is stale. The public fields leave the IRR value’s own change and verification history unresolved.

PeeringDB’s proposed qualifier addresses a narrower problem. Issue #1973 described names that could not be identified, names appearing in more than one IRR, and operators having to review ambiguous values before automating. The August release notes say version 2.82.0 introduced an intelligent AS-SET editor, proactively fixed names whose source was unambiguous, and contacted network owners where it was not. A September product update used AFRINIC::AS-AFRINIC as an example of the source-qualified form and described owner contact when the source could not be determined. Those sources document a product change and a cleanup process; they do not explain why this particular public row still contains the bare name.

What the namespace changes

An AS-SET name identifies a membership definition; it does not carry a copy of its members. RFC 2622 describes an as-set whose members can be AS numbers or other AS-SET names. A tool that consumes the PeeringDB field may use it to locate a record, retrieve it, expand nested membership and eventually turn that result into a filter. If the same unqualified name exists in multiple IRRs, the source qualifier can make the first lookup less ambiguous.

That is a real improvement at the discovery boundary. It is not an end-to-end validation result. The prefix does not show that the record still exists, that its maintainers are authorized, that its membership reflects the network’s intended customers, or that recursive expansion finished without truncation. It does not tell a consumer how to handle referrals, stale replicas or conflicting copies. The name alone cannot establish that a resulting policy matches what the operator meant to accept.

The distinction is operational, not semantic hair-splitting. If an automated pipeline selects the wrong database or receives an empty or incomplete set, it may build a filter that excludes expected routes or includes unintended ones. PeeringDB’s issue itself identifies filter-policy errors as a possible impact of ambiguous names. This research finds no evidence that such an error occurred for ASN 33764, that AFRINIC’s own IRR data is defective, or that this record feeds a live filter. A plausible failure mechanism is not a reported incident.

The remaining proof chain

A safer workflow would preserve the sequence: PeeringDB record and version; selected IRR source; query and retrieval time; returned record identity; recursive member count and result digest; and the downstream policy test. A “verified” label may be valuable, but users need its scope and date before treating it as a decision-grade assertion. The reviewed public page and API expose the label and the string, not that chain.

The right reading of AFRINIC::AS-AFRINIC, when present, is therefore modest: it narrows the source to ask. It does not certify the answer. The bare value in the AFRINIC network record is a concrete reminder that directory data, registry records and routing decisions occupy different control surfaces. A namespace can make the handoff clearer; the consumer still has to prove what crossed it.

Primary evidence: PeeringDB issue #1973, release notes for 2.82.0, PeeringDB’s September update, AFRINIC’s PeeringDB network record, the public API record, PeeringDB API specifications and RFC 2622.