Thank you for bringing this proposal forward. Excedo Networks AB supports enforceable accountability for resource holders that systematically fail to address substantiated infrastructure-level abuse. This response has been reviewed by Excedo Security Operations Center | Digital Crimes Unit. We work on these cases around the clock: investigating active abuse, preserving evidence, coordinating with relevant law enforcement agencies, and pursuing legal avenues, where appropriate, to secure the removal or disabling of abusive hosts and services. In our operational experience, the most difficult cases involve active ASNs registered to shell companies or to companies that have been struck off the relevant company register, while the ASNs and associated prefixes remain operational. In such cases, the registered entity may provide little practical access to the parties exercising actual control. Abuse notifications, contractual notices, and legal escalation can consequently encounter the same underlying obstacle: the registry record does not provide an effective route to an accountable, reachable party. The existence of a shell company does not, by itself, establish abuse. Equally, a company's struck-off status requires verification in the relevant jurisdiction, including any restoration or succession arrangements. However, substantiated abuse combined with evidence that the registered holder no longer exists, cannot be verified, or cannot demonstrate a valid and accountable relationship with the party operating the resources should trigger a substantive review of the registration and contractual relationship. This is a central weakness in the proposed framework. Sending a remediation notice to legal, administrative, and billing contacts assumes that those contacts lead to an identifiable party capable of fulfilling the resource holder's obligations. The proposal must explain what happens when that assumption fails. Repeated notices and a public non-compliance flag are insufficient if the underlying operation continues and the registered counterparty cannot meaningfully be held accountable. We support continued development of this proposal but cannot support adoption of the current text without substantial revision. An effective framework must address both failures to mitigate substantiated abuse and failures of registration integrity. Blocklist inclusion and removal can inform that process, but cannot substitute for verification of the responsible holder, substantive investigation, and demonstrated mitigation. Our comments follow. 1. The policy should define the obligation being enforced The summary describes accountability for resource holders that systematically fail to act on authenticated abuse reports. Article 2.1 instead states that address space must not be systematically utilised to facilitate the defined abuse. These formulations create different obligations. The first concerns a holder's response to substantiated reports. The second could be interpreted as imposing responsibility for the presence of sustained abuse, even where the holder is investigating and taking appropriate action. The policy should distinguish: * Evidence that abuse occurred. * Evidence linking that activity to resources under the holder's responsibility during the relevant period. * Evidence that the holder received an actionable notification. * Evidence that the holder failed to investigate or take reasonable and proportionate measures within its control. A provider should not be considered compliant merely because it acknowledges or forwards a report. Equally, the presence of an abusive customer should not automatically establish that the provider has failed its obligations. We suggest making the enforceable duty explicit: resource holders must investigate substantiated notifications, take reasonable and proportionate measures within their control, and provide sufficient documentation to demonstrate their response. 2. Registry integrity and continued operation under unverifiable or struck-off entities The proposal needs an explicit pathway for cases in which substantiated infrastructure abuse is associated with an active ASN or address resources registered to an entity whose continued existence or entitlement is in doubt. From our operational perspective, this is a major enforcement obstacle. An ASN and its associated prefixes may remain operational even when the registered company has been struck off or the registered structure obscures the parties exercising actual control. An administrative restriction has limited value if it leaves that accountability gap unresolved. Where credible evidence raises such concerns, the RIPE NCC should initiate a documented review to establish: * Whether the registered resource holder continues to exist and has the capacity to maintain the applicable contractual relationship. * Whether an authorised and reachable representative can act on its behalf. * Whether any claimed restoration, succession, transfer, or change of holder is supported by verifiable documentation. * Whether the registration accurately reflects the applicable resource-holding arrangements. * Which party can fulfil the holder's obligations and implement or procure appropriate remediation. The review should distinguish the registered holder, the originating network, and any downstream operator. These may be different parties, and an ASN's appearance in a route does not by itself establish ownership of the announced address space. The policy should also define the consequences of failed verification. It must explain how this process connects to existing contractual and resource-registration procedures where no valid counterparty or entitlement can be established. A holder should not be able to avoid review indefinitely through unreachable contacts, unsupported changes of representative, or nominal transfers that fail to resolve the underlying verification concerns. Any resulting action should follow documented evidence, an opportunity to respond, appropriate review, and assessment of legitimate downstream interests. The objective is to establish an accountable resource holder and a defensible basis for continued registration. A framework intended to address persistent infrastructure abuse must be able to deal with the disappearance or unverifiability of the contractual counterparty. Otherwise, it risks being most effective against cooperative, identifiable operators while leaving the hardest cases untouched. 3. Articles 1.1 and 1.2 need clearer thresholds and attribution rules Terms such as "sustained," "systemic," "dedicated," and "systematically facilitate" are central to the proposal but are not sufficiently defined. For example, the text should explain how an investigator distinguishes a deliberately operated malware distribution network from several compromised services on a legitimate hosting platform. It should also clarify whether the categories in Article 1.1 form an exhaustive list: "defined strictly" and "specifically including" could be read differently. The references to DDoS command-and-control and spam botnet infrastructure also raise a scope question. Are other botnet command-and-control operations deliberately excluded, or are they intended to fall within the definition? Attribution requires similar care. A listed IP address may identify a shared hosting service, proxy, CDN endpoint, reassigned address, or infrastructure operated by a downstream customer. It does not necessarily identify the party controlling the abusive service. The policy should require evidence connecting the relevant activity, time, resources, and responsible relationship. Shared infrastructure should justify further investigation where appropriate; it should not independently establish common malicious control. 4. Article 1.3 should protect subscriber networks without creating an exemption based on self-description We support protecting ordinary residential and dynamic subscriber pools from disproportionate enforcement arising from isolated device compromises. However, the proposed exclusion permits a resource holder's own designation to determine whether an address range falls outside the policy. That could create an avoidance mechanism unless the designation is independently verifiable. The reference to the Spamhaus PBL also requires clarification. The PBL concerns address that should not send unauthenticated email directly to destination mail servers. It can include static as well as dynamic addresses. It is not a global routing registry or an authoritative classification of residential infrastructure. The exclusion should depend on verifiable service characteristics and actual use. It should distinguish ordinary subscriber compromises from deliberately operated malicious infrastructure, including cases where the latter is located within a range labelled as consumer access space. 5. Article 1.4 should separate authentication from evidentiary sufficiency We support authenticated reporting and reliable preservation of evidence. However, authentication does not establish the correctness of an abuse determination. A digital timestamp can support a chronology. A cryptographic signature can support provenance and integrity, subject to verification of the signer. Neither independently establishes that an observation was correctly classified or attributed. The policy should distinguish reporter authentication, evidence integrity, technical validation, and attribution. An actionable evidence package should identify, as appropriate: * The precise resources and services involved. * The alleged abuse category. * First and most recent observations, with a defined time standard. * Relevant technical indicators and collection methodology. * Evidence supporting persistence or recurrence. * Known limitations, uncertainty, and relevant shared infrastructure. * Previous notifications and responses, where available. Sensitive evidence should be available through an appropriate confidential process. Public verifiability should not require publication of victim information, credentials, personal data, or material that could compromise an investigation. 6. Reporting eligibility should include accountable security organisations and authorised representatives Article 1.4 limits qualifying submissions to an affected network operator or a National CERT. This could exclude security providers acting for affected customers, independent researchers, sectoral CERTs, and other incident-response organisations with relevant evidence. For example, Excedo may investigate infrastructure targeting a customer without being the affected network operator itself. It should not be necessary to obtain a National CERT intermediary solely to make otherwise qualifying evidence admissible. We suggest permitting authenticated, accountable reporters and authorised representatives who satisfy the evidentiary requirements. Submission controls should address duplicate, unsupported, or malicious reports without excluding legitimate operational contributors. 7. Article 3.1 should distinguish listing duration from continuing abuse and failure to respond A cumulative fourteen-day listing period may provide a useful persistence indicator, but the policy should not assume that it proves fourteen days of active abuse. A listing may remain after mitigation while a blocklist awaits review or applies its retention rules. Conversely, activity may continue through rotating addresses without any individual address reaching the threshold. The draft should explain: * Whether the threshold measures observed abuse or retained listing status. * What partial days and intermittent observations are counted. * Whether observations from multiple approved lists can be combined. * How address reassignment and changes of control are handled. * How recent the evidence must be when enforcement begins. * Whether corroborated recurrence across addresses can establish a persistent operation. The trigger should also reflect the proposal's stated purpose. If the concern is systematic failure to address reports, prior reporting and the holder's response history are relevant evidence. Any aggregation across addresses or accounts must require a substantiated relationship. A common provider alone should not be sufficient. 8. Article 3.2 needs a complete governance framework for approved blocklists Approved blocklists would have substantial influence over both the initiation of restrictions and their removal. Their governance is therefore a substantive part of the policy. Objective automated telemetry is valuable, but automation does not eliminate classification errors, incomplete visibility, stale observations, or attribution problems. Approval criteria should address: * Published scope and listing methodology. * Alignment with the policy's specific abuse categories. * Historical accuracy and correction practices. * A timely and accessible challenge and delisting process. * Distinction between fresh observations and retained listings. * Operational availability and treatment of outages. * Material methodology changes. * Conflicts of interest and commercial conditions affecting access or correction. * Periodic review and withdrawal of approval. The text should also explain what happens when approved lists disagree, when a list becomes unavailable, or when a listing is successfully challenged. We would welcome concrete examples of datasets capable of meeting all proposed requirements, including the historical evidence requirement. The operational feasibility of those requirements should be demonstrated before adoption. 9. Article 3.3 needs reliable delivery procedures and direct involvement of operational contacts Escalating to contractual contacts is sensible when ordinary abuse handling has failed. However, legal, administrative, and billing contacts should not be the only recipients. The relevant abuse and operational contacts should receive the notice and actionable evidence as well. Automated read-receipt tracking is not a sufficiently defined delivery standard. The policy should distinguish acceptance by a mail system, a recipient-generated acknowledgement, and tracking-pixel activity. These provide distinct kinds of evidence. The process needs defined retries, alternative contact methods, and a fallback where delivery cannot be confirmed. Otherwise, an unresponsive operator may prevent the grace period from starting, while a cooperative operator may dispute a misleading delivery timestamp. Notifying contacts across a member's LIR accounts may improve visibility. That should not automatically extend an abuse finding or restriction to unrelated resources. 10. Article 3.4 should distinguish response, mitigation, and closure A single seven-business-day deadline treats several different tasks as though they were interchangeable. Acknowledging a report, commencing an investigation, containing immediate harm, completing remediation, and obtaining third-party delisting may require different actions and timescales. The policy should recognise a substantive response and verifiable containment while preventing indefinite delay through generic assurances that an investigation is ongoing. It should also define which business-day calendar applies and use consistent terminology: Articles 3.4 and 3.6 currently refer to "business days" and "working day." Separately, the contractual process should not delay urgent operational escalation. Serious continuing harm may require immediate coordination with hosting providers, upstreams, CERTs, or other appropriate parties while the contractual review proceeds. Our own internal escalation thresholds serve an operational purpose. We would not propose importing them as universal contractual deadlines without assessing the relevant responsibilities and implementation requirements. 11. Article 3.5 cannot be evaluated without the actual restrictions The proposal acknowledges that its effectiveness depends on restrictions to be specified separately. Those restrictions are the enforcement mechanism, so they should be available for community review before adoption. "Operational registry agility" and "registry architecture deployment" do not define which functions would be restricted, how restrictions would be scoped, or how comparable cases would receive comparable treatment. For each proposed measure, the community should be able to assess: * The function being restricted. * The resources, accounts, and parties affected. * Its expected contribution to remediation. * Its effect on legitimate downstream users. * Whether it could obstruct corrective action. * Its duration, review process, and restoration conditions. Retaining underlying assignments does not, by itself, guarantee that legitimate connectivity will be unaffected. Depending on their design, restrictions could interfere with operational changes needed for remediation. Public flags may also influence third-party filtering decisions. Conversely, an established abusive operator may have little immediate need to change registry data. The proposal should explain why the selected restrictions would meaningfully influence that operator's behaviour. 12. Article 3.6 should remove ROA deletion as a standalone compliance criterion This is a substantive technical objection. A Route Origin Authorisation states which AS is authorised to originate a prefix. Deleting it does not withdraw the BGP announcement, disable the hosted service, or demonstrate that the abuse has stopped. Depending on remaining covering authorisations, the announcement may become Not Found, remain Valid, or become Invalid. None of those outcomes independently proves remediation. The current clause could therefore permit restoration while the abusive operation continues. It could also create an incentive to remove routing-security protections. ROA deletion should not constitute standalone proof of compliance. There is also an inconsistency between Articles 3.4 and 3.6. Article 3.4 accepts verified administrative isolation, while Article 3.6 narrows restoration to delisting or ROA deletion. A holder could therefore satisfy one provision without satisfying the other. Both provisions should use consistent criteria based on verified mitigation. Delisting can contribute to that assessment, but there must be an alternative where mitigation is established, and the listing remains stale or disputed. The commitment to restoration within one working day is welcome. However, a deadline measured only from completion of verification leaves the verification period itself undefined. The policy should specify when review begins and how promptly a decision must be made. 13. Procedural safeguards must be part of the framework The draft does not expressly provide an opportunity to challenge the evidence, an independent appeal, or a process for correcting erroneous public findings. Before restrictions or a public non-compliance label are imposed, the holder should receive sufficient information to understand and respond to the case, subject to necessary confidentiality safeguards. The framework should provide: * A reasoned decision identifying the evidence and unmet obligation. * A defined review or appeal mechanism. * Rules governing whether restrictions are paused during review. * Expedited correction of demonstrably erroneous decisions. * Clear scope, review dates, and removal procedures for public labels. * Separate treatment of duplicate, withdrawn, or invalid notifications. The requirement to resolve every notification before restrictions are lifted also needs care. Duplicated or contested submissions should not indefinitely prevent restoration after the substantiated matters have been resolved. These safeguards protect both legitimate resource holders and the credibility of enforcement. 14. The contractual and administrative assumptions require assessment The rationale states that failure to remediate would constitute a boilerplate Material Breach and presents the process as a binary administrative audit. We believe both claims require qualification. The community should have a RIPE NCC legal assessment explaining how the new obligations and intermediate restrictions interact with the applicable agreements and existing procedures. The assessment should distinguish members, sponsored resource holders, and other relevant contractual arrangements rather than assume that every holder has an identical direct relationship with the RIPE NCC. Similarly, the process necessarily involves decisions about scope, attribution, exceptions, sufficiency of remediation, and proportionality. These decisions remain substantive even when external telemetry is used. The administrative burden should therefore be estimated through an implementation assessment. A fourteen-day threshold and manual submission requirement may reduce volume, but they do not establish how many cases, disputes, or repeat notifications the NCC would need to handle. A documented process with clear review responsibilities would provide a stronger foundation than an assumption that substantive evaluation can be avoided. 15. Effectiveness should be measured through outcomes The framework should include a defined review after implementation. Useful measures would include time to substantive response, time to verified mitigation, recurrence, successful appeals, erroneous findings, collateral impact, and RIPE NCC handling effort. The number of notices issued, restrictions applied, or addresses delisted would be insufficient on its own. The question is whether the framework materially reduces persistent abuse while treating responsible operators fairly. To conclude, we support the objective of stronger contractual accountability and welcome further work on the proposal. Our support for adoption would depend on a framework that: * Establishes a clear duty to investigate and take appropriate action. * Requires substantiated attribution and evidence of failure. * Establishes a defined verification and enforcement pathway where the registered resource holder is unverifiable or has been struck off, while its ASN or associated prefixes remain operational. * Uses blocklists as reviewable evidence. * Defines proportionate restrictions and downstream safeguards. * Provides meaningful review and appeal. * Recognises verified mitigation consistently. * Removes ROA deletion as standalone proof of compliance. We would welcome the proposer's and RIPE NCC's views on these points, particularly the technical basis for Article 3.6, the intended restrictions under Article 3.5, and the evidentiary standard for distinguishing sustained abuse from systematic failure by the resource holder. Excedo Networks AB Michael Duffy CEO/CISO michael.duffy@excedo.se