Summary
- Number-resource policy needs authors who understand registration systems, allocation requests, transfers, routing security and member operations. Excluding implementers would remove much of the knowledge required to write workable rules.
- The governance risk is not expertise but an unmarked change of role. A person may speak as proposer, employer representative, working-group chair, registry employee, software operator or affected resource holder, and the audience may not know which authority is being exercised.
- RIR processes already contain useful separations: APNIC states that registry staff do not participate in consensus; RIPE describes secretariat support and public impact analysis; APNIC and RIPE publish proposal histories and implementation material. These controls should be extended into a durable implementation record.
- Every adopted policy should carry an intent map, decision log, test cases, conflict declarations, public implementation plan, launch report and post-implementation review. Material choices not settled by consensus should return to the community rather than hardening silently in forms, code or staff guidance.
The same expertise creates both legitimacy and risk
Internet number-resource policy is not written in an abstract parliament. It is written by people who operate networks, request address space, maintain registration data, advise customers, build registry systems, investigate abuse, review transfers, chair technical discussions and interpret the rules in difficult cases. Their proximity to implementation is usually why their contribution is useful. A proposal drafted without operational knowledge can be elegant on a mailing list and impossible at a service desk.
That fact makes a simplistic conflict rule self-defeating. The community cannot protect policy by excluding everyone who may later apply it. An engineer who understands RPKI failure modes may also deploy certificate services. A registry analyst who can identify an ambiguous needs test may later train the team that conducts requests. A network operator proposing a transfer rule will almost certainly use, advise on or compete under that rule. Expertise and interest are not opposites; in specialised governance they are often inseparable.
The harder question is what happens when the same person's authority changes without becoming visible. During discussion, an author asks the community to accept a problem statement and policy text. During implementation, an operator decides what evidence a request form will demand, how exceptions are escalated, what a database status means, when a case is rejected and which edge condition requires manual review. Those decisions can alter the practical distribution of rights even if no sentence in the adopted policy changes.
Implementation therefore cannot be treated as a neutral mechanical act. It is a bounded act of interpretation. The boundary is legitimate when the community can see which choices were compelled by the adopted text, which were necessary technical details and which introduced a new substantive condition. When that record is absent, a knowledgeable author can become a second policymaker after consensus, not necessarily through bad faith but through the ordinary pressure to make a system work.
A policy has at least three authors
The named proposer is only the first author. The public discussion becomes a second, collective author by adding objections, narrowing language and establishing the reasons on which consensus depends. The implementation team becomes a third author when it translates words into forms, software, internal instructions, evidence thresholds and customer communications. Each contribution is real, but they do not have the same mandate.
The named proposer has initiative. They can choose the initial framing, examples and remedy. The community has deliberative authority. It may accept the remedy only after assurances that a feared consequence will not occur. The registry has execution authority. It must deliver a coherent service under law, security constraints and existing technical architecture. Confusion begins when one of these roles claims the authority of another.
An implementation team cannot say that an operational choice represents community consensus merely because it is convenient and compatible with the text. Compatibility is broader than authorisation. A proposer cannot privately settle ambiguity with implementers by saying what they always intended if that intention was neither written nor tested during discussion. Chairs cannot convert an explanatory remark into binding language unless the community had a fair opportunity to assess it. Conversely, the community cannot require staff to perform an unsafe or unlawful action by assuming implementation has no constraints.
The proper model is a chain of accountable authorship. The proposal supplies text and rationale. The discussion record identifies accepted meaning and unresolved limits. The impact assessment tests feasibility and exposes choices. The implementation plan maps each operational decision to one of those public authorities. Where no authority exists, the choice is labelled administrative and constrained against changing eligibility, burden, priority or remedy. If it would change one of those, it returns for policy consideration.
What the current RIR processes already recognise
The APNIC Policy Development Process makes an important separation explicit: RIR, ICANN and PTI secretariat staff do not participate in consensus. The community discusses proposals in the Policy SIG, chairs observe general agreement, the membership confirms, the Executive Council endorses and the APNIC Secretariat implements. This does not remove staff knowledge from the process; impact assessments and operational input remain available. It marks the difference between informing a decision and counting as the constituency that makes it.
The RIPE Policy Development Process describes the RIPE NCC as providing administrative support, facts, statistics, drafting assistance when requested and an impact analysis explaining effects and implementation work. Working-group chairs guide discussion and declare milestones. The model acknowledges that the secretariat sees consequences that volunteer proposers may not see, while placing that knowledge in published material rather than treating it as a private veto.
The RIPE working-group chair role also requires chairs to make clear whether they speak personally, for an employer or for the working group. That is a small but powerful governance principle. A person's knowledge does not need to be suppressed; the capacity in which the knowledge is offered needs to be legible.
APNIC publishes proposal pages with versions, history, secretariat impact assessment, endorsement and implementation dates. RIPE proposal pages preserve versions, state and rationale. These practices create the beginnings of an accountability chain. Yet the most consequential implementation choices often remain spread across service announcements, procedure pages, software releases and staff explanations. The public can see that a policy was implemented without always seeing how each contested sentence became a decision rule.
The author-implementer is not one category
Overlap takes several forms, and a useful control must distinguish them. The most direct case is a registry employee who proposes a rule and later works on the operational change. A second is an employee who assists a community author with text, writes the impact assessment and then implements it. A third is a working-group chair whose employer will benefit from or administer the result. A fourth is an operator who authors a policy, helps explain it to registry developers and then uses it for clients. A fifth is a consultant whose commercial value increases because the rule becomes complex.
These situations have different powers. A public proposer can influence framing but cannot normally change registry code. A staff analyst may have no vote in consensus yet possess decisive control over evidence design. A chair can determine whether objections are addressed even without touching implementation. A consultant may have no formal role but can dominate the interpretation because few others understand the proposal. Treating all overlap as a prohibited conflict would be both unfair and ineffective.
The material question is whether the person can make or strongly shape a decision that affects eligibility, burden, timing, priority, disclosure, sanction or appeal. If so, the role and interest should be declared, the decision should be reviewable and another qualified person should check it. If the person's task is limited to correcting a typographical error or configuring an agreed date, disclosure may be enough. Governance should follow power, not titles.
This approach also avoids moralising expertise. A network operator does not become suspect merely because an adopted policy affects its resources. The community needs to know the direction and scale of the effect, whether the author has a client interest, and whether alternatives were presented fairly. It then judges the argument on evidence. Conflict transparency is a tool for interpreting participation, not a substitute for substantive debate.
Problem statements can carry implementation interests
Much policy power is exercised before the rule appears. The problem statement determines what counts as failure and which people appear as victims, beneficiaries or administrative burdens. An author who will implement the remedy may naturally define the problem in the terms their systems can solve. A registry team may describe inconsistent documentation as a customer-compliance problem when the underlying issue is an ambiguous form. An operator may describe delay as staff resistance when the request actually presents unresolved title risk.
The answer is not to demand a view from nowhere. It is to require a plural problem record. A proposal should distinguish observed facts, operational symptoms, author interpretation and normative objective. It should state whose experience produced the diagnosis and which affected groups were not consulted. Implementation constraints can then be evaluated as constraints rather than disguised as the definition of the problem.
Counterfactuals are especially valuable. What happens if the policy is not adopted? What non-policy remedies exist? Could a procedure change, clearer guidance or better tooling resolve the issue? If the author is part of the implementation organisation, these questions test whether a policy mandate is being sought for a management choice. If the author is an affected operator, they test whether a shared rule is needed or whether the proposal socialises one business model's costs.
Chairs should insist that objections to the problem statement are addressed before debate collapses into line editing. Once entities negotiate exact text, they become invested in a solution and may overlook that the diagnosis was partial. A published issue map can preserve competing explanations without requiring unanimous agreement about motive. Consensus can then rest on a clearly stated problem even when entities reach it from different experiences.
Impact assessment can illuminate or pre-decide
Operational impact analysis is essential. It can identify legal conflict, security exposure, database migration, staffing cost, inconsistent terminology, cross-registry dependency and an implementation interval the author did not anticipate. A community that ignores this knowledge may approve a rule that cannot be administered. But an impact assessment can also function as a hidden amendment if it presents one interpretation as inevitable.
Suppose a proposal requires stronger validation of a resource-holder fact. Staff may estimate cost based on annual documentary review, even though event-triggered verification or risk sampling would also satisfy the text. The cost then appears to be a property of the policy, and entities may reject the proposal on that basis. In reality, the assessment bundled the rule with an unchosen operating model. The reverse can occur when a low estimate assumes automation that later proves unreliable and shifts burdens onto applicants.
A robust assessment should separate mandatory consequence from implementation option. It should identify assumptions, alternatives, uncertainty and the distribution of burden. Legal analysis should say whether a risk is prohibited, manageable or simply novel. Technical analysis should distinguish current-system cost from enduring policy need; a legacy platform must not silently define what the community is permitted to choose.
The author should be allowed to respond, but not privately negotiate the decisive interpretation. Staff comments, author answers and revised assessment should be public and versioned. If the same staff member helped draft the proposal, another reviewer should test the assessment for omitted alternatives. This is not a judgment on integrity. It recognises that people tend to validate the architecture they helped design.
Drafting assistance needs an attribution boundary
Registry employees often help proposers turn an idea into precise text. This can widen access by helping entities who lack legal drafting experience or use another first language. It can also make policies more consistent with the existing manual. Refusing assistance would favour insiders who already know the vocabulary. The danger lies in invisible co-authorship.
Every proposal should state the kind of drafting assistance received: formatting only, editorial clarity, technical data, legal review, operational design or substantive wording. Names are less important than institutional capacity, though a responsible contact should be recorded. If staff suggested a material condition, the proposal history should show it. If the proposer rejected advice, the impact assessment can explain the consequence without presenting the final text as staff-approved.
The boundary matters because readers interpret a community proposal differently from a registry initiative. A staff-shaped proposal may be entirely legitimate, but entities should know whether the organisation that will execute the rule also designed its central mechanism. That knowledge may prompt questions about alternatives, budget, enforcement and institutional convenience. Concealment denies the community the opportunity to ask them.
Attribution also protects staff. Without a record, a disappointed entity may later claim that the registry wrote a policy through a nominal volunteer. A transparent assistance note shows what was and was not done. It allows the organisation to support drafting without inheriting political authorship of every argument.
Consensus does not approve every implementation detail
Community discussions rarely resolve every branch. Entities may agree that a registry should validate a fact but not specify acceptable documents. They may support a transfer condition without deciding how a queue handles simultaneous requests. They may adopt a routing-security obligation without determining retry intervals. Some detail must remain operational because policy manuals cannot become software specifications.
The key is to classify discretion. Type one is compelled: the policy explicitly requires an outcome. Type two is bounded: several means satisfy the text, and staff can choose among them without materially changing access or burden. Type three is constitutive: the choice effectively determines who qualifies, what they must reveal, how long they wait or what remedy they have. Type-three choices require renewed public authority.
An implementation matrix should list each material decision and its class. For bounded choices, it should explain criteria such as security, cost, accessibility and reversibility. For constitutive choices, it should identify a follow-up proposal, consultation or narrow community confirmation. This keeps the registry from pretending that code merely copies prose, while avoiding the impossible demand that every interface field receive full policy debate.
The matrix should include negative assurances that mattered to consensus. If chairs concluded that a proposal would not retrospectively disturb existing holders, the implementation record must show how migration protects them. If the community accepted a rule because manual alternatives would remain, a later automation-only design cannot be dismissed as procedure. Reasons are part of the mandate when they were necessary to resolve objections.
Software can become the most authoritative policy text
For an applicant, the operative rule may be a required field, a validation error or a caseworker's checklist. A policy manual can promise flexibility while the portal accepts only one document type. It can permit judgment while a database state forces rejection. It can protect an exception that no service path exposes. In those moments software is not supporting policy; it is replacing it.
This is why implementation review must inspect user journeys rather than only revised manual text. Test cases should cover ordinary applicants, small networks, public institutions, cross-border organisations, legacy holders, people using assistive technology and cases with incomplete digital records. Edge cases reveal where an author's assumptions became a universal burden.
Policy authors can help write these tests because they know the intended remedy. They should not be the only people who approve them. At least one reviewer should represent registry operations, one should be independent of the proposal and affected users should be invited to challenge the cases. The tests and expected outcomes can be published without exposing security-sensitive controls or personal information.
After launch, the registry should compare real outcomes with the expected cases. A sudden rise in rejected requests, repeated manual overrides or unequal delay across applicant types is evidence that implementation may have created policy. Aggregate data can reveal the problem without disclosing customer files. The author-implementer should be able to explain anomalies, but an independent owner should decide whether remediation is procedural or requires community reconsideration.
Casework discretion must not remain private precedent
No implementation plan anticipates every case. Staff will interpret terms, balance evidence and decide whether a novel arrangement fits. Those decisions create precedent even if the registry says they are case-specific. If only the original author or a small operational group knows the rationale, similarly situated applicants may receive different results.
A de-identified decision register can preserve material interpretations. It should state the question, relevant policy language, outcome, reasoning, date and whether the decision is temporary. Repetitive administrative matters do not need publication. Decisions that clarify eligibility, evidence, timing, priority or sanctions do. Security and privacy can be protected by abstracting facts.
The register allows the community to detect drift. If exceptions accumulate in one direction, the policy may be poorly written. If an implementation team repeatedly relies on an assumption not found in the consensus record, the issue should return to the working group. If outcomes are stable and uncontroversial, the next editorial revision can codify them openly.
An author who later manages cases should disclose that overlap in the register's governance, not in every entry. Another person should approve precedent-setting decisions, and a route for internal reconsideration should exist. The objective is not to paralyse operations. It is to prevent practical law from becoming the memory of one expert.
Chairs are part of the overlap problem
The author-implementer story often focuses on staff, but chairs can carry equal influence. Chairs guide a proposer, decide whether text is ready, frame the state of discussion, determine whether objections were addressed and declare consensus. They may also work for organisations that will use the policy or possess deep operational views about its design.
The RIPE expectation that chairs distinguish personal, employer and working-group speech should become a universal habit. A chair can contribute expertise, but should hand facilitation to a co-chair when advocating a substantive position. A chair who materially helped author a proposal should not make its consensus declaration. Where both chairs have conflicts, a temporary neutral facilitator can be selected before the decisive phase.
Recusal must be functional rather than ceremonial. Leaving the microphone while privately drafting the consensus summary does not remove influence. The record should identify who moderated, who assessed objections and who signed the decision. Co-chairing provides redundancy only when responsibilities genuinely move.
The same principle applies after adoption. Chairs may be asked to clarify what the community intended. They can point to the record, but should not issue private interpretations that bind staff. If the record is ambiguous, that is evidence for public clarification, not an invitation for the chair to become an oracle.
Commercial implementation deserves equal scrutiny
Many policy authors work for service providers, brokers, hosting companies, consultancies, security vendors or large resource holders. Their organisations implement registry policy internally by deciding which customers qualify, which evidence is collected and how resources are priced or routed. This is not registry implementation, yet it can shape the policy's real market consequences.
A transfer-policy author may later advise clients on transfers. An abuse-contact author may sell compliance services. A routing-security author may provide validation products. These interests do not invalidate the proposal. They do create incentives toward complexity, mandatory process or a technical architecture that rewards existing capability.
Conflict declarations should therefore cover material commercial benefit, not merely registry employment. The declaration should be concrete enough to inform judgment: employer sector, relevant product or client class, and whether the author expects to implement or advise on the rule. Exact compensation and customer identities are usually unnecessary. Changes during a long-running proposal should be updated.
Competing implementations should be considered before consensus. If a proposed obligation can be met only through one vendor architecture, the community should know. Open standards, exportable records and proportional compliance options can reduce capture. Post-implementation review should ask whether the rule concentrated business or created consultancy dependence beyond what its public purpose required.
Small communities magnify unavoidable overlap
RIR policy groups are not national legislatures with large professional staffs. A limited number of volunteers may understand a specialised issue. The same names recur because sustained participation is costly. Strong recusal rules can therefore remove everyone capable of resolving the problem, leaving formal independence and practical ignorance.
The answer is graduated safeguards. Disclosure is the baseline. Independent review applies to material decisions. Recusal applies where a person exercises procedural authority over their own proposal or implementation dispute. External expertise can be invited when local capacity is too concentrated. Decisions can be reversible and time-limited while evidence accumulates.
Institutions should also invest in widening the expert pool. Fellowships, translated summaries, remote participation, implementation briefings and public test environments enable more people to scrutinise proposals. Documentation reduces dependence on oral history. A community that relies on one author to explain and implement a rule has a succession problem as well as a conflict problem.
Workload matters. Volunteers cannot review hundreds of pages for every small change. A materiality threshold should focus attention on choices affecting access, distribution, rights, sanctions, privacy, security and appeal. Routine configuration can remain with accountable staff. Proportionality makes transparency sustainable.
An implementation hearing should test fidelity, not rerun consensus
Before a major policy launches, the registry should publish an implementation plan and hold a focused review. The question is not whether entities still like the policy. It is whether the proposed execution faithfully carries the accepted text and reasons. Reopening the merits whenever an opponent dislikes an interface would make implementation impossible.
The plan should show scope, dates, affected services, migration, evidence requirements, system changes, manual alternatives, staff training, privacy effects, security assumptions and expected user outcomes. It should identify unresolved choices and name their authority. The author may present intent; implementers explain constraints; affected users test usability; chairs state the consensus record.
Comments should be triaged into defects, policy questions and preferences. A defect contradicts adopted language or a material assurance. A policy question exposes a choice the community did not settle. A preference concerns a bounded operational method. Defects are corrected, policy questions return to an authorised public route, and preferences are decided by staff with reasons.
This hearing creates a clean transition from authorship to administration. Once complete, no individual author's private intention outranks the published map. The implementation team receives a defensible mandate, and the community gains a record against which later drift can be measured.
Launch is the beginning of evidence
Adoption often ends community attention just as the strongest evidence appears. Real requests show whether a definition works, whether burdens fall unevenly and whether staff rely on exceptions. A policy designed by its future implementers needs especially careful evaluation because its assumptions may be embedded throughout the service.
A launch report should appear after a defined interval, commonly three to six months for high-volume processes and longer for rare events. It should compare forecast with outcome: request volume, completion time, rejection reasons, appeals, manual interventions, system incidents, cost and distributional effects. Data should be aggregated and limitations stated.
The report should record changes made after launch. Emergency fixes are sometimes necessary, but each should have authority, owner and expiry or review date. A collection of small fixes can produce a materially different rule. If so, the community should consider a revision rather than allow operational sediment to become permanent policy.
Review must include people other than the original author and implementation lead. They should contribute because their knowledge remains valuable, but another body should decide whether the evidence shows fidelity. This can be a working group, advisory council, independent review panel or time-limited community team depending on the RIR's structure.
Appeals need access to the implementation record
An applicant challenging a decision cannot make a meaningful case if the operative interpretation is invisible. Nor can a policy entity contest implementation drift by citing only broad text while the registry relies on unpublished technical constraints. The decision log, test cases and impact assumptions should therefore be available to whatever review mechanism hears complaints.
An appeal should ask four questions. What did the adopted policy require? What implementation classification authorised the disputed choice? Was the rule applied consistently to the facts? Has new evidence revealed a policy gap rather than an individual error? These questions separate correction of a case from amendment of the general rule.
The author-implementer should not be the final reviewer. They may explain the design and provide evidence, but a separate decision-maker must assess it. If the appeal exposes an ambiguity that only the author can resolve, the system has already failed; public policy cannot depend on inaccessible intention.
Published appeal outcomes should feed the decision register and post-implementation review. Repeated reversals are evidence of defective guidance. Repeated complaints rejected on the same ground may show that public instructions are unclear even if decisions are lawful. Accountability is not only about identifying wrongdoing; it is about learning where the rule produces avoidable conflict.
A workable integrity standard
The following standard preserves expertise without granting invisible power. At submission, authors disclose relevant employment, commercial interests, registry roles and expected implementation involvement. Drafting assistance is attributed by type. The problem statement distinguishes evidence, interpretation and alternatives. Chairs declare conflicts and transfer facilitation where they have materially shaped the proposal.
During assessment, the registry publishes assumptions, mandatory effects, implementation options, costs, legal constraints and uncertainties. A reviewer independent of substantive drafting tests material alternatives. The author answers publicly. Consensus summaries record decisive objections, assurances and boundaries, not only support counts or a conclusion.
After adoption, an implementation matrix maps material choices to policy authority. Constitutive choices return to the community. Test cases include diverse users and adverse conditions. A public plan precedes launch; a de-identified interpretation register follows it. Material changes carry reasons and review dates.
After operation begins, outcome data tests the forecast. Independent reviewers assess fidelity, with the author and implementers heard but not controlling the conclusion. Appeals can inspect the record. When practice has changed eligibility, burden, priority, disclosure, sanction or remedy, the text is amended through the proper public process.
This standard does not assume corruption. It assumes that implementation contains judgment, that specialists carry multiple roles and that institutions are more trustworthy when those transitions are visible.
The legitimacy test is whether another team could reproduce the rule
A mature policy should survive the departure of its author. Another implementation team should be able to read the proposal, discussion summary, impact analysis, decision matrix, tests and review reports and reach substantially the same outcomes. If it must telephone the drafter to discover what a phrase really means, the institution has not adopted a public rule; it has adopted a personal dependency.
Reproducibility is a stronger integrity test than the absence of declared conflict. A person can have no financial interest and still exercise excessive interpretive control. Another can have an obvious interest yet produce a transparent, testable design that the community can scrutinise and replace. What matters is whether authority is transferable through public reasons.
The test also improves resilience. Staff turnover, vendor changes, litigation, emergencies and system migrations all force policies into new hands. A reproducible implementation record allows continuity without freezing old assumptions. New teams can see which choices were provisional and where the community retained discretion.
For members, reproducibility creates equal treatment. Applicants need not know the original author or possess insider history to understand the rule. For authors, it is the final proof that their expertise became institutional knowledge rather than private power.
Procurement can hide a fourth implementation author
Registries do not necessarily build every service themselves. A contractor may configure identity checks, case management, voting, document review or security controls. Procurement teams translate a policy requirement into specifications, and vendors translate those specifications into product constraints. This creates a fourth author whose choices may be less visible than staff interpretation.
A contract can narrow a community rule without changing the policy manual. A vendor may support one evidence format, one queue model or one identity assumption. Customising it may cost enough that staff describe the product limitation as an operational necessity. The institution then inherits private architecture as public meaning.
Material specifications should therefore appear in the implementation matrix before contract award. Procurement confidentiality can protect price and security details, but not the fact that a product would determine eligibility, evidence, timing or appeal. Competing bidders should be assessed against published policy test cases. A vendor's inability to satisfy a required exception is a product defect, not authority to erase the exception.
Contracts should preserve data export, audit access, change records and the registry's ability to replace the service. A policy must not become dependent on a supplier's undocumented interpretation. When a contractor helped design a substantive mechanism, that assistance belongs in the attribution record just as staff drafting does.
Post-launch review should include vendor-caused outcomes: cases blocked by product limits, manual workarounds, accessibility failures and changes imposed through upgrades. The public need not see proprietary code to know whether outsourced implementation remains faithful. Accountability follows delegated power, even when the person exercising it never appeared on the policy mailing list.
Vendor staff who later advise on policy revisions should disclose the implementation relationship. Their evidence may be uniquely useful, especially where product limits produced repeated exceptions, but the commercial answer should not define the public problem. The registry should publish enough performance information for alternative suppliers and independent engineers to challenge claims of inevitability. A community rule remains public only when no contractor owns the sole practical explanation of how it works.
Conclusion: mark every change of hat
Policy communities should welcome implementers as authors because workable rules require people who understand consequences. They should welcome authors into implementation because intent can prevent avoidable error. But every change of hat must be marked, and no hat should carry authority borrowed from another.
The proposer persuades. The community authorises. Chairs assess the process. The secretariat advises and executes. Boards or councils perform the roles assigned to them. Reviewers test fidelity. The same person may occupy several positions over time, but not invisibly and not as the sole judge of their own work.
That is the difference between practical expertise and capture. Capture does not require a secret conspiracy. It can arise when a sensible operational choice is never exposed, when a helpful drafter becomes the only interpreter, or when software settles an objection that public discussion left open. Transparent role changes, public implementation reasons and independent review turn those risks into manageable governance.
Number-resource policy earns legitimacy not when it pretends implementation is automatic, but when it makes the human choices between consensus and service visible. The author who also implements the rule should be neither disqualified nor trusted by title. They should be accountable through a record strong enough that the community can understand, challenge and, when necessary, change what their expertise built.