The APNIC 62 Policy Call Is Open: What Separates a Submitted Proposal From an Adopted One
A confession from my side of the desk. Over the years I have logged a stubborn pattern in how operators try to fix the address rules they live under, and APNIC's latest call for proposals is the cleanest example yet of why that pattern keeps repeating. Someone who runs a real network, who has hit a real wall in how addresses get allocated or how routes get validated, finally writes the problem down and sends it to the Policy SIG list. And then nothing happens to it. Not because the idea was bad. The proposal was a description of a frustration, and the community could only act on a piece of policy.
The call for proposals for APNIC 62 opened on 8 June and closes 7 August 2026. The meeting runs in Mumbai from 4 to 10 September, with the Open Policy Meeting (OPM) on 10 September at 9:30 (UTC +5:30). Dave Phelan's announcement makes the open invitation explicit: you do not need to be a long-term policy expert to contribute, and some of the most valuable input comes from people with fresh operational experience rather than years of debate history.
I work the IPv4 market for a living, mostly across the Asia Pacific economies APNIC serves, and I agree with the invitation completely. What I want to add is the part the announcement, by design, leaves out. Openness gets you to the mailing list. It does not get you to consensus. The distance between those two points is the whole game, and it is closeable.
Why "anyone can contribute" is true and still misleading
The diversity argument in Phelan's post is not boilerplate. APNIC is the largest Regional Internet Registry by population and land mass, covering 56 distinct economies that differ in language, network maturity, regulatory regime, and what "normal" even looks like for an operator. A policy written from inside one advanced market routinely breaks when it meets a network two economies over running older gear, tighter margins, or a different legal frame. That is precisely why the process needs operators who are not already policy insiders: they know where the rules will actually fail.
So the openness is genuine. What catches people out is reading "you don't need to be an expert" as "you don't need to be precise." The PDP does not lower the bar for rigor just because it lowers the bar for credentials. A proposal still has to name a concrete problem, propose a specific change to a specific policy, and survive people asking why it should not be done some other way. New contributors fail when they walk through an open door carrying a grievance instead of a specification.
Ground the proposal in a problem you can actually point to
Phelan names the kinds of issues the community wants: address management, routing security, resource distribution, emerging operational challenges. He also names the shape of a good proposal, a problem someone is trying to solve, an inefficiency they have encountered, a gap they think the community should close. Read that as a test, not a list of topics.
Here is the test I apply before I would put my name on anything. Can I state the problem as a specific failure another operator could verify against their own network, rather than as a general wish? "Routing security should be better" is the wish version, and it dies on the list in a week. "Holders of out-of-contract legacy space have no obligation to maintain a working abuse contact, so incidents on that space cannot be reported" is the working version. It is checkable, it is bounded, and it points at a policy lever. That second one earns argument, which is exactly what you want.
Routing security is the clearest case of why grounding matters. The community is in the middle of a long push toward RPKI and origin validation, and on paper "mandate it" sounds clean. In practice, strict origin validation can drop legitimate announcements from older systems and from holders who never created the supporting registry objects, the kind of legacy and out-of-contract space that is thick on the ground across this region. A proposal that ignores that failure mode reads as naive to the operators who would have to live with it. A proposal that addresses it head-on signals that its author has actually deployed the thing, and that difference decides whether your idea gets engaged or skipped.
A pre-submission checklist that does the work the list will do anyway
The Policy SIG mailing list is where proposals get refined before the meeting, and it is unsentimental. The useful move is to run your own draft through the same questions the list will ask, before you send it. Every line here should be true before you hit submit.
| What to check | A good answer | Why it changes the call |
|---|---|---|
| Concrete problem | A failure another operator can reproduce or recognize | The list rejects grievances; it engages with verifiable gaps |
| Specific change | Names the exact policy text or mechanism you want changed | "Something should be done" cannot reach consensus |
| Regional reality | Holds across diverse economies, not one advanced market | APNIC spans 56 economies; single-market rules stall |
| Failure modes named | You state where your own proposal could break | Pre-empting the obvious objection earns credibility |
| Defensible in person | You can answer "why not the alternative?" out loud | The OPM is live discussion, not an email thread |
The last row is the one new submitters underestimate. A proposal can read well in writing and still come apart when someone asks, in the room, why you did not do it the other way. The Policy 101 session from APRICOT 2026 in Jakarta exists exactly for this. It runs a simulated OPM, walking an example proposal through the full PDP so you see the shape of the questioning before you are on the receiving end of it. If you are new, or returning after time away, watch it before you write, not after.
Where I think the process genuinely under-serves new voices
I will not pretend the system is frictionless, because it is not, and pretending otherwise is how you lose the people you most want to keep. The real weak point is timing and access. The mailing-list-then-meeting rhythm rewards people who can engage early and sustain a thread for weeks; an operator firefighting a live network does not always have that bandwidth, and a genuinely urgent operational issue does not wait for the next cycle to open. There is real tension between the deliberate pace consensus requires and the speed at which operational problems actually arrive.
Access compounds it. Much of the relationship-building and informal problem-solving that the announcement rightly praises happens in person, in the hallway conversations and mentoring that surround the formal sessions in Mumbai. That is valuable, and it is also gated by who can physically get there. The fellowship program that offsets travel cost had its 2026 application deadline back on 13 March, which has passed. For this cycle, that means a remote operator's leverage runs through the list and the asynchronous channels, so plan your participation around that constraint rather than discovering it in September. None of this is a reason to stay out. It is a reason to be deliberate about how you get in.
About
I am Alexei Krylov, Head of Sales at InterLIR, a Berlin-based IPv4 marketplace. My day job is moving address space between the parties who hold it and the parties who need it, which keeps me inside Regional Internet Registry processes and the legal scaffolding around IP resource ownership most working weeks.
I came into this from a civil-law background, so the contract questions never quite leave the room when I read a policy draft. That vantage is why APNIC policy matters to me commercially as well as professionally: the rules set here decide how allocation, transfer, and routing security work across the fastest-growing address market in the world. Enough well-intentioned proposals have died on me for want of precision that I now treat the fix as teachable, and I would rather operators in this region shape these rules than inherit them.
Conclusion
The APNIC 62 call is a real invitation, and I would take Phelan at his word. If you run a network in this region and you have hit a wall the community should care about, write it down and send it in before 7 August. The position I have been defending all the way down comes to this in plain terms. The proposals that change anything share four traits: they are grounded in a verifiable problem, specific about the change they want, candid about where they might break, and ready to be defended out loud.
So run your draft against those four traits before you submit. Watch the Policy 101 simulation so the OPM holds no surprises, and engage the Policy SIG list early enough that the rough edges come off in email instead of in the room. The door is open. Whether you walk through it with a specification or a complaint is the one variable that is entirely yours to set.
Frequently Asked Questions
Correct. APNIC explicitly welcomes operators and newcomers, and values fresh operational experience over debate history. What it does still require is precision: a concrete, verifiable problem and a specific proposed change. The credential bar is low; the rigor bar is not.
The call for proposals runs from 8 June to 7 August 2026. The APNIC 62 meeting is in Mumbai from 4 to 10 September, and the Open Policy Meeting where proposals are discussed is on 10 September at 9:30 UTC +5:30. Pre-meeting refinement happens on the Policy SIG mailing list.
Because APNIC covers 56 economies that differ in network maturity, regulation, and operating conditions, a rule written for one advanced market often breaks elsewhere. Proposals that hold up across that diversity reach consensus; single-market assumptions tend to stall during review.
Watch the Policy 101 simulated OPM from APRICOT 2026 to see how a proposal moves through the full process, then engage the Policy SIG mailing list early so weaknesses surface in writing first. Be ready to defend your choice against alternatives out loud, since the OPM is live discussion.
They describe a frustration instead of specifying a change. A proposal needs a problem another operator can verify, a specific policy lever, and an answer to "why not do it another way?" Grievances get skipped on the list; grounded, defensible proposals get engaged with.
