I understand the objective of establishing a common definition, but I think the inclusion of “unlawful conduct” creates an operational question that needs to be resolved as part of this proposal rather than left entirely to a future obligations discussion. But just want to highlight that for the numbers community, the 2016 IANA transition was principally about who would oversee and perform the IANA Numbering Services after the US Government’s NTIA contract ended. The numbers proposal was deliberately based on the existing RIR system, with minimal operational change. It created an SLA between the RIRs and the IANA Numbering Services Operator, plus performance-review and accountability mechanisms for that service only.
The proposed definition includes conduct that is unlawful where the resource holder has the practical and/or operational ability to address it. The proposal also recognises that some conduct will be jurisdiction-dependent and specifically identifies matters such as gambling as requiring further consideration but there are more such as DNS amplification and others. The difficulty is determining which jurisdiction applies. APNIC’s contractual relationship with its Members is governed by State of Queensland law (as per membership agreement), but APNIC Members operate across many different legal jurisdictions (56 economies in APNIC service region). An activity may be perfectly lawful where the resource holder is located, lawful where the infrastructure is hosted, but unlawful in the jurisdiction from which the complaint originates or where the service is targeted. For example, if an APNIC Member receives an abuse report concerning an online gambling service, which law determines whether the activity falls within the definition of “Internet Abuse through IP Addresses”? Is it the law of the resource holder, the customer, the server location, the target market, the complainant, or Queensland law because that governs the APNIC Membership Agreement? This becomes more important because Section 6 says that, in practice, the existing duty to monitor and respond to abuse complaints would for the first time apply against this agreed definition, including jurisdiction-dependent unlawful conduct. That suggests the definition is not entirely neutral from an operational perspective. There is also an unresolved question about fair judgement (lack of better word). The proposal states that the resource holder determines in the first instance whether conduct constitutes abuse, while APNIC does not have the power to judge/decide abuse. At the same time, APNIC is described as retaining responsibility for holding resource holders accountable for responding to and addressing abuse, but how? If the complainant and the resource holder disagree about whether the underlying conduct is unlawful, how would APNIC determine whether the resource holder has fulfilled its responsibility without making a direct or indirect determination about the underlying conduct? We are operational community, I think it would help the community if the proposal included a few concrete operational scenarios covering: - conduct that is lawful in one jurisdiction and unlawful in another; - disagreement between a complainant and a resource holder; - the difference between acknowledging/investigating a complaint and being required to stop the underlying activity; and - what exactly APNIC would assess if a complaint is escalated. Clarifying these points would help determine whether this proposal is genuinely only defining terminology, or whether the definition also creates a new practical threshold against which resource-holder behaviour could later be assessed and have to look at this proposal under the light of prop-125 implementation proposal as well. Regards, Aftab A. Siddiqui On Mon, 10 Aug 2026 at 13:09, Shaila Sharmin <[email protected]> wrote: > Dear Colleagues, > > > A new proposal "prop-172: Defining Internet Abuse through IP Addresses" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 62 on > Thursday, 10 September 2026. > > https://conference.apnic.net/62/program/program/index.html#/day/7/ > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important part > of the Policy Development Process (PDP). > > We encourage you to express your views on the proposal: > > · Do you support or oppose this proposal? > > · Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > > · Do you see any disadvantages in this proposal? > > · Is there anything in the proposal that is not clear? > > · What changes could be made to this proposal to make it more > effective? > > > Information about this proposal is appended below as well as > https://www.apnic.net/community/policy/proposals/prop-172/ > > Regards > Bikram, Shaila, and Ching-Heng > > APNIC Policy SIG Chairs > > > > -------- > > > ------------------------------------------------------- > > prop-172-v001: Defining Internet Abuse through IP Addresses > ------------------------------------------------------- > > Proposer: Alban Kwan > [email protected] > > > > > 1. Problem statement > ------------------------------------------------------- > APNIC is a "steward" of Internet number resources in the Asia Pacific. That > role is widely recognised: it was reaffirmed through the 2016 IANA > stewardship transition, and NTIA, ICANN, RIPE, and LACNIC all use the same > language to describe it. But "stewardship" only describes what we do — > coordinating the allocation of Internet number resources. It doesn’t define > what a good steward actually looks like. > > That raises a real question: what is a good steward? Are we a good steward > just by distributing resources correctly? Are we still a good steward if > those resources are later misused and cause harm to Internet users? > > This is a conundrum the community needs to confront as we carry out that > stewardship — especially now, as national governments regulate the Internet > more actively. The multistakeholder model needs to strike that balance, > without APNIC overreaching its role. > > This is where "Internet Abuse through IP Addresses" comes in. APNIC requires > resource holders to maintain an abuse-mailbox, monitor it, and respond to > complaints. But APNIC policy never defines what "abuse" actually means. That > gap makes enforcement almost impossible, and it is part of why practices like > bulletproof hosting persist. Left unaddressed, it also invites more > government regulation — the opposite of what the multistakeholder model is > meant to achieve. > > Without agreeing on what "Internet Abuse through IP Addresses" means, the > community has no shared vocabulary to even discuss the gap. This proposal is > limited to closing that definitional gap. It does not propose new > obligations, enforcement powers, or compliance mechanisms — those are left > for separate, future proposals. > > > > 2. Objective of policy change > ------------------------------------------------------- > This proposal introduces a clear and explicit definition of "Internet Abuse > through IP Addresses" (or "IP address abuse") into APNIC policy documents. > If adopted, APNIC policy would, for the first time, contain an agreed > definition of this term. That definition would: > • identify the categories of conduct that constitute IP address abuse; > • state how such conduct is adjudicated in the first instance, and clarify > APNIC’s own role in that process; and > • be precise enough to serve as a stable foundation for any future policy > proposal on resource holder obligations. > This proposal does not aim to create any new obligation, reporting > requirement, or compliance mechanism. Section 4 does describe a resource > holder’s responsibility to respond to abuse, and APNIC’s role in holding them > accountable for doing so — but that responsibility already exists under > APNIC’s current policy requiring resource holders to monitor and respond to > abuse reports. Whether any further obligations should attach to this > definition is left for future policy discussion. > > > > > 3. Situation in other regions > ------------------------------------------------------- > All other Regional Internet Registries (RIRs) have adopted policy requiring > resource holders to maintain a registered abuse contact (commonly "abuse-c") > for their address space. None of them, however, has defined IP address abuse > at the policy level, or required resource holders to act once they receive an > abuse report. > > > 4. Proposed policy solution > ------------------------------------------------------- > The following definition is proposed for adoption into the relevant APNIC > policy document. The specific document and section would be confirmed through > community discussion; the IRT object provisions in the APNIC Whois Database > documentation are one likely location. > > "Internet Abuse through IP Addresses" means the use of an IP address, or set > of IP addresses, registered to or held by an APNIC account holder, in a way > that causes technical harm to the security, stability, or trust of the > Internet. It also includes facilitating unlawful conduct that the resource > holder has the practical and operational ability to address. This includes, > without limitation: > • distributing or hosting malware, including botnet command-and-control > infrastructure; > • originating, amplifying, or reflecting Distributed Denial of Service (DDoS) > traffic; > • deliberate or grossly negligent routing-layer abuse, including BGP > hijacking, and the use of unallocated, reserved, or squatted address space; > • fraudulently acquiring, transferring, or sub-allocating IP address > resources to facilitate the above; > • hosting infrastructure used for phishing, fraud, scam, or the impersonation > of a legitimate entity for deceptive purposes > > Good-faith operational errors that are identified and promptly corrected — > including inadvertent routing misconfigurations — do not constitute abuse > under this definition. Nor does it constitute abuse for unlawful conduct to > occur on a resource holder's network at the hands of a third party — such as > a customer, user, or employee — where the resource holder addresses that > conduct promptly on being notified of it, consistent with this definition. > > Adjudication of whether reported conduct constitutes abuse rests, in the > first instance, with the resource holder. This applies where the resource > holder has been notified by a party with a legitimate basis to report it, and > has the practical ability to act. An isolated instance of delayed or > imperfect response does not, on its own, constitute abuse under this > definition; this definition is directed at conduct and patterns of > non-response, not individual lapses. > > Acting in good faith to address reported conduct of this kind — including > reasonable reliance on a substantiated notice — does not itself constitute > abuse. It also does not, on its own, create a broader monitoring obligation, > or amount to an admission of liability beyond what this definition > establishes. Resource holders are encouraged, but not required, to retain a > record of any notice received and the action taken in response, so that > good-faith reliance under this section can be demonstrated if later disputed. > > For the avoidance of doubt, APNIC does not have the power to adjudicate > abuse. As steward of Internet number resources, APNIC retains its existing > responsibility to hold resource holders accountable for responding to and > addressing abuse. > > Note for further discussion (not operative policy text): > > Responsibility for the conduct above may reasonably differ depending on a > resource holder's registered or predominant use of its IP addresses (e.g., > access/transit network, hosting/content provider, enterprise/internal-use > network) — consistent with existing cross-industry practice, such as M3AAWG's > separate best-practice guidance for hosting providers versus network > operators. This proposal does not resolve how, or whether, such > differentiation should be built into policy; it's raised here for future > community discussion, alongside the related question of what notice standards > and processes (for example, for copyright, fraud, or > jurisdictionally-targeted unlawful conduct such as gambling) would be > appropriate if this definition is later used as a basis for obligations. > > > > > 5. Advantages / Disadvantages > ------------------------------------------------------- > Advantages: > • Establishes a shared, technically precise vocabulary for discussing > IP-address abuse within the APNIC community, where none currently exists. > • Gives the community a stable, narrowly scoped starting point for any future > discussion of resource holder obligations, reducing the risk that substantive > policy questions become mired in definitional disagreements. > • Closes a real coordination gap for content-adjacent conduct (such as > phishing, fraud, and scam) that falls outside ICANN's own remit, while > keeping adjudication with the resource holder and expressly excluding speech- > and content-moderation-style complaints (e.g., misinformation, > disinformation, defamation) that would risk broader scope creep. > • Anchors the malware, DDoS, and routing-layer categories in conduct that > APNIC's own technical infrastructure -- the Honeynet Project and DASH -- > already detects and surfaces to Members, so those categories reflect > operational reality rather than introducing novel or untested conduct. > • Creates no new compliance mechanism of its own; the monitoring and response > expectations described in Section 4 restate an obligation that already exists > under current APNIC policy, rather than adding a new one. > > > Disadvantages: > • A definition with no attached obligation may be seen by some community > members as insufficient to address the underlying problem, or as a procedural > step that delays substantive action. > • Some categories within the proposed definition, particularly routing-layer > abuse and resource transfer fraud, may be perceived as overlapping with > existing routing security initiatives (e.g., RPKI, MANRS) or future transfer > policy discussions, requiring careful scoping during community discussion to > avoid duplication. > • Defining a term in policy, even without attached obligations, may create > community expectation that obligations will follow, potentially generating > debate disproportionate to this proposal's limited scope. > • Placing adjudication with the resource holder in the first instance, and > extending the definition to some content-adjacent conduct (e.g., phishing, > fraud, scam) and to jurisdiction-dependent conduct, will likely raise > community questions about who ultimately decides contested cases, and about > whether this represents a first step toward content-related enforcement. This > proposal does not resolve either question - both are raised here for > community discussion, alongside how any future obligations proposal might > address them. > > > > 6. Impact on resource holders > ------------------------------------------------------- > For resource holders, what changes in practice is that the existing duty to > monitor an abuse-mailbox and respond to complaints — which currently has no > defined trigger — would for the first time apply against an agreed definition > of "abuse," including the phishing, fraud, and scam category and the > jurisdiction-targeting rule for other unlawful conduct described in Section > 4. Resource holders retain the primary role in deciding whether reported > conduct falls within that definition, and are protected by the good-faith > safe harbor in Section 4 for reasonable action taken on a substantiated > notice, including where that judgment is later disputed or shown to be > mistaken. Resource holders whose registered use includes web hosting, email > hosting, or content delivery are likely to see this definition engaged more > often in practice than those operating purely as access or transit networks — > though this proposal does not itself differentiate obligations by resource > holder type; that question is raised for future discussion in the note at the > end of Section 4. > > > 7. References > ------------------------------------------------------- > • APNIC, "Security at APNIC," www.apnic.net/community/security/ > • APNIC, "Update on the APNIC Honeynet Network," APNIC Blog, 5 February 2024, > blog.apnic.net/2024/02/05/update-on-the-apnic-honeynet-network/ > • APNIC, "How DASH helps monitor network health," APNIC Blog, 9 September > 2020, blog.apnic.net/2020/09/09/how-dash-helps-monitor-network-health/ > • APNIC, "Introducing Network Vulnerability Detection in DASH," APNIC Blog, > 11 December 2025, > blog.apnic.net/2025/12/11/introducing-network-vulnerability-detection-in-dash/ > • DNS Research Federation, "China and India registered ASNs lead in malware > distribution through IP addresses," 4 October 2023, > dnsrf.org/blog/china-and-india-registered-asns-lead-in-malware-distribution-through-ip-addresses/ > • DNS Research Federation, "Use of Subdomain Providers Gains Popularity as a > Mechanism to Launch Phishing Attacks," 14 August 2023, > dnsrf.org/blog/use-of-subdomain-providers-gains-popularity-as-a-mechanism-to-launch-phishing/ > • DNS Research Federation, "Measuring Internet Abuse through IP addresses -- > Live indicators," > dnsrf.org/measuring-internet-abuse-through-ip-addresses---live-indicators > • American Registry for Internet Numbers, "Grant Report: Measuring Internet > Abuse via IP Addresses," 8 January 2026, > www.arin.net/blog/2026/01/08/2024-grant-report-dnsrf/ > • RIPE NCC, "RIPE NCC Anti-Abuse Support -- What to Do if It Happens to You," > RIPE Labs, > labs.ripe.net/author/angela_dallara/ripe-ncc-anti-abuse-support-what-to-do-if-it-happens-to-you/ > • RIPE NCC, "Top 3 Types of IP Address Abuse That Threaten IPv4 Resource > Holders," RIPE Labs, > labs.ripe.net/author/vincentas-grinius/top-3-types-of-ip-address-abuse-that-threaten-ipv4-resource-holders/ > • CircleID, "Looking Ahead: ICANN's Upcoming Policy on DNS Abuse Mitigation," > circleid.com/posts/looking-ahead-icanns-upcoming-policy-on-dns-abuse-mitigation > > > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected]
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
