APNIC Policy 101: How policy shapes operations — and how Policy Fellows are making participation easier

Internet number resource (INR) policy determines how IPv4, IPv6, and Autonomous System Number (ASN) resources are managed and distributed across the Asia Pacific. Policy can sometimes seem abstract or administrative, but it has real consequences.

Policy can affect routing, contactability during incidents, the accuracy of registry data, and how networks interact with the wider Internet.

At APRICOT 2026 in Jakarta, the Policy 101 session took this reality head‑on. It showed how operators, security teams, National Internet Registries (NIRs), and other stakeholders can influence policy to better reflect day‑to‑day needs. The session also demonstrated the work APNIC’s 2025 Policy Fellows are doing to make policy development more accessible, more transparent, and more representative of our region.

The APNIC Policy Development Process: A quick explainer

The APNIC Policy Development Process (PDP) is open, transparent, and community‑driven. All decisions are made in public. There is no voting — proposals advance only when the community reaches consensus.

The PDP steps are:

1. A proposal is submitted and posted to the Policy Special Interest Group (SIG) mailing list.
2. Discussion occurs on the list, where authors receive early guidance, support, and objections.
3. The proposal is presented at an APNIC Open Policy Meeting (OPM) for further discussion and a consensus call.
4. If consensus is reached, the proposal is taken to the APNIC Annual Member Meeting (AMM) or Annual General Meeting (AGM) for confirmation. If not, it goes back to the list, and the cycle begins again.
5. After the AMM/AGM consensus, it is posted back to the list for a final comment period.
6. If consensus is maintained, the APNIC Executive Council (EC) instructs the Secretariat to implement it.

This process only works when the community engages by asking questions, pointing out conflicts with existing policy, raising operational impacts, and helping authors refine their proposals.

The Policy 101 session simulated this cycle in a compressed, interactive format — led in part by APNIC’s Policy Fellows.

Inside the Policy 101 simulation

During the session, Policy Fellows Christopher Hawker and Tsung-Yi Yu served as SIG Chairs. Doctor Saima Nisar created a realistic example proposal that was intentionally imperfect. Its purpose was to show how community input improves a draft, and how policy changes flow from operational concerns.

The Policy Fellows led the group through a typical OPM structure, from policy pitch to clarifying questions, followed by discussion and objections, which led to new information introduced by stakeholders. The simulation finished with a chair‑led consensus call.

The example proposal: Improving whois contact accuracy

Participants were told:

• APNIC already performs Incident Response Team (IRT) contact validation every six months.
• Many whois contact records remain outdated or unresponsive.
• This causes delays during abuse cases, routing incidents, and security events.
• A community‑authored proposal aimed to extend contact validation to administrative contact (admin-c) and technical contact (tech‑c) roles.

To address these issues, Doctor Nisar introduced prop‑DA101: Improving whois contact accuracy through annual validation and structured remediation, which proposed:

• Annual validation of admin‑c, tech‑c, and IRT contacts.
• Automated emails with confirmation links
• Marking contacts ‘invalid’ after non‑response
• Potential restrictions on some MyAPNIC functions
• Publication of periodic validation statistics

The problem statement aligned with operational experience. Outdated contacts reduce the reliability of whois data and slow down cross‑network coordination. But the proposal raised several important concerns.

Operational and administrative concerns

Operators highlighted practical issues, like how staff turnover might affect responsiveness and put a provider’s access at risk, or how local holidays might lead to missed notifications.

A Computer Emergency Response Team (CERT) member noted that 22% of abuse‑related notifications to Member contacts were bouncing. This added urgency to the problem statement and prompted questions about whether remediation windows should be shorter during active incidents.

Privacy advice raised concerns about the wording around publishing statistics. There was concern that aggregated data must be designed carefully to make sure individual Members are not identifiable.

Session facilitators also highlighted that the proposal conflicted with the existing IRT validation policy, which uses different timelines. Real proposals face the same requirement: New text must not introduce contradictions inside the policy text.

These kinds of cross‑functional impacts often arise late in policy discussion — and the simulation reflected this reality.

Evolution and consensus

After gathering all this input, the author returned with v002 of the proposal with a clearer remediation workflow, narrowed MyAPNIC restrictions, stronger privacy safeguards, and alignment with existing policy timelines.

This progression illustrated how feedback transforms a draft into something more workable, fair, and implementable. Once discussion finished, the Chairs conducted a consensus call. Participants indicated their level of support on a scale from strongly supported to strongly objected.

A strong objection must include a clear explanation, so that policy authors have a chance to update their proposals to address the objector’s concerns.

After reviewing the ‘feel in the room’ and considering the mailing list context, the Chairs determined that the community had reached consensus on the revised proposal. In a real OPM, this would mean the proposal moves on to the AMM for further confirmation.

This exercise showed participants what consensus looks like in practice. Not a vote, but a recognition of broad agreement and an understanding of remaining concerns.

Key takeaways: Making policy development accessible

Several themes emerged from the Policy 101 session:

1. Policy affects operations: Outdated contacts delay incident response. Incomplete policies cause friction. Good policy reduces operational overhead and improves coordination.
2. Policy improves through community input: Operators, CERTs, Local Internet Registries (LIRs), NIRs, privacy specialists, and APNIC staff each brought valuable perspectives that strengthened the proposal.
3. Policy development is accessible: The Fellows helped demonstrate that anyone can participate — you do not need to be an expert, and questions are encouraged.
4. The PDP is transparent and collaborative: Every stage, from mailing list discussion to OPM consensus, is open. Decisions are made based on general agreement.
5. More participation leads to better policy: Policy that reflects the diversity of operational environments in the Asia Pacific ultimately leads to a more stable and secure Internet.

How you can participate

Whether or not you attended APRICOT, you can be part of policy development:

• Join the Policy SIG mailing list
• Read current proposals and follow the discussion
• Attend Open Policy Meetings in person or online
• Ask questions, raise operational considerations, and offer feedback

Participation is how you make sure your needs and day-to-day operational reality are reflected in policy. You don’t need to be an APNIC Member or a long‑time contributor — the PDP depends on voices from across the region.

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.