Summary

  • APNIC’s current policy tests whether an IRT contact can be reached. Prop-171 asks a different question: when resources are passed to a downstream network, can a report travel from that registered contact to the people able to investigate?
  • APNIC 62 returned the proposal to the mailing list without consensus. Its unresolved terms—“reliable operational path,” proof of forwarding and what the Secretariat should validate—matter more than the proposal’s broad statement of intent.

A message can arrive and still go nowhere useful

The difference between a reachable mailbox and an actionable report is easy to miss in a registry record. A message can be delivered, perhaps even acknowledged, while the person who receives it has no access to the affected network, no authority to request a change and no established route to the downstream operator. The contact is technically alive. The operational chain may not be.

APNIC prop-171, titled “Operational Accountability for Abuse Contacts in Sub-Allocated Address Space,” was designed around that distinction. Its first version says APNIC-127 requires an Incident Response Team object for each resource record and periodically validates the listed contact. A contact that answers the validation message shows that an address is reachable. It does not necessarily show that a report sent there will be delivered to the organization able to inspect the relevant customer, prefix, router or service.

This is a structural issue in networks where an address holder supplies connectivity or address space to another organization. The upstream provider may maintain the registry object and a central abuse desk. The downstream party may operate the actual network. Several intermediary tiers can separate them. The registry’s public record is a useful index, but the report still has to cross the operational boundaries behind it.

The proposal authors say operational data indicates that a significant share of certain APNIC reports about non-responsive or non-functional IRT contacts originate in sub-allocated address space. The proposal gives no counts, denominator, period, sampling method or independently testable data for that assertion. It should therefore be read as the proposers’ account of the problem, not as a quantified finding about the region or all abuse reports.

What the proposal would change—and what it would not

Prop-171 would add a principle: when address space is sub-allocated, assigned or otherwise used by a downstream organization, the upstream holder should ensure a reliable operational path from the registered abuse or IRT contact to the party responsible for handling reports for that address space. It deliberately leaves the arrangement open. The registered contact might be operated by the downstream network; an upstream central desk might identify the relevant customer and forward the report; or another arrangement might work if legitimate reports reach the responsible party without undue delay.

That flexibility is important. A single mailbox model cannot describe every hosting, wholesale, enterprise or managed-network structure. Nor does the proposal require public disclosure of every downstream customer contact. A downstream security team may need to be reachable without publishing personal addresses or exposing internal escalation maps to the Internet.

The proposal also says it would not change the existing validation interval or create a new audit or compliance mechanism. It would not make APNIC an abuse investigation body or give the Secretariat new enforcement authority. Those exclusions distinguish the proposal from a request that the registry decide whether a report is true, compel a network change or adjudicate a dispute between a reporter and provider.

Yet the distinction does not eliminate the implementation question. If APNIC does not inspect report contents or audit operators, how would an upstream holder demonstrate that the path is reliable? A policy might require a tested mailbox-to-team route, an escalation record, a response acknowledgement or a declared allocation of responsibility. Each proof option has different privacy, cost and gaming risks. A formal contact field alone cannot show whether the next handoff works.

The Secretariat identified the gap in the wording

The Secretariat’s impact assessment agrees that the central issue is not a Whois schema change. It is the meaning of “reliable operational path,” and how anyone would define or validate it. The assessment notes that the proposal sets no minimum size for a sub-delegation. In a large organization, many small network segments could have different operators or contacts; a lookup might return multiple contacts for one address. The more granular the obligation, the more important it becomes to say what an upstream holder must actually maintain.

The Secretariat also raises two tensions. First, existing policy may already cover some arrangements: a resource holder can create customer-specific IRT objects or use its own IRT when it remains responsible. Prop-125 also leaves an upstream holder responsible for contact validation when a downstream contact is invalid or unresponsive. Second, the current rule does not clearly define responsibility for what happens after a report reaches a valid contact. The proposal attempts to close that space, but its terms could be interpreted as a new enforcement expectation even while the proposal says it creates none.

That tension is not semantic housekeeping. It defines the control surface. If APNIC is expected to test whether a report reached a capable operator, the registry may be drawn into reviewing forwarding arrangements, downstream responsibility and complaints about delay. If the upstream holder alone is responsible, the rule needs to identify the evidence and remedy that make the obligation meaningful. If the downstream operator owns handling, the record must tell the reporter where the responsibility sits while preserving a reliable escalation path.

“No consensus” leaves a design task, not a verdict

At APNIC 62, the Policy SIG did not reach consensus on prop-171 and returned it to the mailing list. That means participants did not agree that the text was ready to proceed under the policy process. It does not mean the proposal was adopted, nor that the operational concern was rejected as false. APNIC’s outcome report and its later conference summary both describe the return for further discussion.

There is also a small recordkeeping wrinkle: the individual prop-171 page still labels the proposal “For Discussion at APNIC62 OPM,” while APNIC’s general proposals page records that it did not reach consensus and belongs on the Policy SIG mailing list. That stale event label is not evidence of a hidden decision; it is a reason to use the outcome record and current proposal list when tracking status.

A revised draft would become more testable if it separated four questions: which organization owns the resource record; which party operates the affected network; who receives and forwards the report; and what evidence establishes that the handoff occurred. It should then state what “without undue delay” means for policy purposes, or explain how the community will settle that standard. A rule need not impose one response-time target on every incident, but the phrase needs a process that can be checked.

The design should also distinguish a report’s receipt from its resolution. A registry can help make a contact route discoverable and keep records valid. It cannot infer that a complaint is accurate, that the reporter’s requested action is warranted or that the downstream team can disclose its investigation. Any confirmation mechanism should establish delivery to the responsible party without turning APNIC into a merits tribunal or publishing sensitive customer data.

APNIC-127 already requires monitored contacts and six-monthly validation. That is a real baseline, not an empty rule. Prop-171 asks whether the next handoff is included in the responsibility that makes the baseline useful. The APNIC 62 return leaves that question open. Until revised text defines a proportionate, privacy-aware and testable route, “reachable” and “accountable” remain two different claims.

Sources

  • APNIC, prop-171 page and current page status. Link
  • APNIC, prop-171 v001 text and Secretariat assessment. Text
  • APNIC 62 official report and Policy SIG outcome. Report
  • APNIC Blog, APNIC 62 Policy SIG proposal outcomes, 25 September 2026. Article
  • APNIC, active APNIC-127 v015 policy text. Policy
  • APNIC, prop-125 contact-validation proposal record. Link
  • APNIC, current policy-proposals status list. List
  • APNIC, Policy Development Process. Process
  • Heng Lu Note 65, “Running-Code Primacy” (editorial lens only). Link