Summary

  • Aftab Siddiqui’s APNIC record connects two distinct channels: he authored a formal ROA policy proposal and, as Routing Security SIG chair, co-authored a report on a survey of possible APNIC services.
  • The proposal left a public trail from versions to consensus, a guideline and an implemented status. The survey recorded preferences for ROA notifications and APIs; it did not direct a product release or demonstrate safer routing.

Two channels, two kinds of receipt

An Internet registry can hear an operator in more than one way. A proposed rule may travel through a defined policy process, where versions are discussed, a community position is recorded and an implementation status can later be published. A product question may instead begin as service feedback: useful evidence for deciding what to investigate, but not an order to build it.

Aftab Siddiqui’s public APNIC record places him near both. In 2021 he proposed restricting which autonomous-system numbers could be entered as the origin in a Route Origin Authorization, or ROA. Separately, while chairing the Routing Security Special Interest Group (SIG), he co-authored an account of a survey asking whether operators wanted features such as ROA notifications and APIs for managing ROAs. These are adjacent technical concerns, but they are not the same decision pathway.

That distinction matters because registry records sit upstream of routing behavior. An API can make it easier for an authorized user to change records. A ROA can state which autonomous system is authorized to originate a prefix. But routers apply their own validation and routing policies. A survey about a management feature is not evidence that a correct ROA was created, published, validated, or acted on by a network.

A charter built for feedback, not release authority

At APNIC 49 in 2020, the meeting report describes a chair election and discussion of the existing Routing Security/RPKI SIG’s name and charter. Following community endorsement, the group was renamed the Routing Security SIG, its charter was agreed, and Siddiqui was elected chair. The charter calls the SIG a forum for operational problems and good practice. It also says the group can collect operator feedback on APNIC services such as RPKI, IRRd, and RRDP, and advise the community on technical elements of routing-security policy proposals.

That remit gives the forum a practical bridge: operators can describe where a service fits awkwardly into their work, and APNIC staff can hear what changes might help. It does not give the SIG authority to set APNIC’s product priorities or commit the services team to a release. Siddiqui described the bridge similarly in his 2022 chair nomination statement, saying the SIG could discuss operational problems and value-added features or support that APNIC might provide. He also said the group had lost momentum during COVID. Those are his contemporaneous views, not an independent measure of participation or performance.

The boundary is visible in the next step. A 2022 APNIC blog, co-authored by Siddiqui, Di Ma, and Afifa Abbas, said the services team was expected to present cost-benefit analysis for the proposed features at APNIC 54. The forum could put an operational question on the agenda; the service owner still had to assess the costs and decide what to do.

What the survey counted—and left out

The blog says the Routing Security SIG surveyed participants after its October 2021 open session. On whether APNIC should send email when a ROA is created, 52.4% said yes, 33.3% favored an opt-in option, 9.5% said no because of notification volume, and 4.8% wanted more discussion. Among those who supported notifications, 47.6% preferred webhooks, 28.6% said email was sufficient, and 23.8% were unsure. Asked about APIs for ROA management—through MyAPNIC or self-hosted RPKI software such as Krill—66.7% said yes, 19% no, and 14.3% maybe.

Those figures are a useful record of expressed preference. The published account does not provide the denominator, response method, or a breakdown by network type. It therefore cannot show how many people answered, whether respondents represented APNIC members or operators generally, or whether the percentages speak for the region. Nor is it a vote on routing policy: the questions concern possible service features, and one answer explicitly leaves room for further discussion.

The survey does show the kind of operational friction the SIG was designed to surface. A notification can alert a technical contact that a ROA has changed; a webhook can route that signal into an operator’s own systems; an API can support repeatable changes without manual portal work. Each option shifts a different part of the workflow. None, by itself, determines whether a ROA is correct or whether a router will reject an invalid route.

A later API is not a causal receipt

In October 2024 APNIC announced that its Registry API was available. The service supports retrieval of delegation data and management of Whois records, reverse DNS, ROAs, and route objects. APNIC said the API responded to requests from members and described automation as a way to replace some manual MyAPNIC changes. A 2022 annual report had earlier described a prototype for public testing and scheduled production development for 2023.

The overlap with the survey is real but limited: both concern API access to registry functions, including ROA management. The public record cited here does not say that the 2021 survey caused the API project, that the survey’s respondents were the members whose requests prompted launch, or that the SIG selected the product design. The API’s later availability is not a deployment receipt for any respondent’s network, and it is not a measurement of fewer route leaks or hijacks.

That separation is easy to lose because “routing security” can name several layers at once. A registry may expose a control surface; an account holder may use it to create or update a ROA; the registry may publish signed data; a validator may consume those data; and a network may decide how to treat the resulting validation state. Evidence about one layer should not be silently promoted into evidence about the next.

The policy proposal left a different trail

Siddiqui’s prop-138 proposal offers a useful contrast. It argued that APNIC’s ROA management system allowed origin ASNs that were private, reserved, or unallocated, and proposed preventing their use. The second version extended the corresponding restriction to route and route6 objects. APNIC’s public tracker records the proposal’s two versions in August and September 2021, consensus at the September APNIC 52 Open Policy Meeting to proceed as a guideline, publication in December, and a current status of “Implemented.”

This is a more formal decision record than a service survey: the subject is a proposed rule, the versions and consensus date are named, and the tracker records an implementation status. It still does not establish how many problematic records were prevented, whether every existing record was corrected, or how much routing risk changed. “Implemented” identifies a process state; it is not an impact study.

The contrast is not between a serious policy process and an unimportant survey. It is between different institutional outputs. A policy forum can record whether a proposed rule reached the community’s defined decision point. A service survey can help identify preferences and questions for a product owner. To evaluate either pathway, a reader needs the appropriate receipt: the policy status for the rule, a product specification and release record for the service, and operational evidence for downstream effects.

What the record says about Siddiqui

APNIC’s 2012 nominee page described Siddiqui as a network-operations manager in Pakistan involved in IPv6 deployment, infrastructure security, the IPv6 Task Force Pakistan, and regional operator activities. A later APNIC 54 page records his own account of chairing the Routing Security SIG and his interest in connecting operational discussion to APNIC support. These dated records show a practitioner moving between operator concerns, policy discussion, and service feedback. They do not make him the sole author of the group’s direction or the decision-maker for APNIC systems.

The fairest assessment is correspondingly specific. Siddiqui authored a proposal whose status can be followed through APNIC’s policy record; he also helped chair a forum that documented service preferences and brought them to the services team. The first pathway has an explicit consensus and implementation trail. The second created a signal for product consideration. Later API availability makes the issue tangible, but does not fill the missing causal link or prove an operational security result.

Sources