Summary

  • On 12 August 2018, Abuse Contact Policy Update Draft 1 proposed a mandatory abuse-c contact on directly issued inetnum, inet6num and aut-num records, replacing an earlier system in which use of a dedicated IRT-based contact object was encouraged but optional.
  • Its validation ritual sent a URL and a code in two consecutive plain-text emails, gave the contact two business days to complete a CAPTCHA-protected attestation, then gave the LIR three more business days before permanent invalidity; another failed check could become a policy breach with revocation-related follow-up.
  • A registry may require one reachable role mailbox and test objective deliverability. It may not use that record to dictate filters, forms, manual handling, measures or responses, because AFRINIC is a private technical bookkeeper, not an abuse regulator or public authority.

L3 — The five-day validation machine

The mechanism began with two consecutive plain-text emails. The first carried a validation URL. The second carried a unique code. The person controlling the proposed abuse-c mailbox had no more than two business days to open a CAPTCHA-protected form, paste in the code and tick an attestation. That checkbox did not merely say that the address could receive mail. It asked the person to affirm that the mailbox was regularly monitored, that measures were taken and that an abuse report received a response. If the code remained unused, the contact became temporarily invalid and AFRINIC staff would follow up with the local Internet registry, or LIR. The member then had no more than three additional business days to correct the problem. Failure at the end of that second window made the contact permanently invalid. A later validation failure could be treated as a breach of policy, with more exhaustive follow-up under procedures especially concerning resource revocation.

That compressed sequence matters because it reveals the institutional question before any abstraction can hide it. In five business days, a field in a public number-resource directory could travel from “not yet verified” to “permanently invalid”. On repetition, the matter could travel again, from inaccurate contact data to policy breach and the shadow of resource-related procedures. The opening issue was therefore not whether abuse reporting deserved attention.

It was whether a private registry’s sensible interest in a working address could justify supervising what happened behind the address and placing the member’s registry relationship at risk.

The proposal was Abuse Contact Policy Update Draft 1, identified as AFPUB-2018-GEN-001-DRAFT01. Jordi Palet Martinez submitted it on 12 August 2018 to replace section 8.0 of AFRINIC’s Consolidated Policy Manual. It was an under-discussion proposal, not an operative rule. That status is essential. The document records an attempted institutional design; it does not prove that the first draft was adopted, implemented or used against any member.

The starting point was not an empty directory. AFRINIC already had an abuse-contact arrangement developed in 2011 and described as implemented in 2012. It used a dedicated IRT-based object for publishing abuse contact information. Resource records such as inetnum, inet6num and aut-num could refer to that object, but the reference was optional. Members were encouraged to publish the information as good practice. The weakness was obvious: encouragement could leave a directly issued resource without a clear, current and uniform abuse desk. A reporter might search several records, write to a general administrative address, or guess at the responsible operator. A mailbox preserved only in an obsolete object could accept no messages at all.

Draft 1 proposed a much firmer directory rule. Every number resource allocated directly by AFRINIC would have to include an abuse-c contact in the corresponding inetnum, inet6num or aut-num WHOIS entry. At least one associated abuse mailbox had to be valid, monitored and actively managed. Child objects did not necessarily need a separately staffed desk: they could inherit the parent contact or publish their own. The address was to remain available without restriction through WHOIS, application interfaces and whatever access techniques followed. At this level, the proposal addressed a genuine defect in public registry data. A common field makes the point of contact legible. Inheritance reduces duplication. An objective check can expose a dead role account before a live incident makes the failure costly.

The validation schedule made the field a recurring interaction rather than a static declaration. AFRINIC would check it when a record was created or updated, at least once every three months, and whenever AFRINIC saw fit. The proposal’s example used the paired URL-and-code messages, but it allowed some tests to vary domains, subjects and message bodies. That variation was intended to prevent a sham arrangement that recognised only the known validation message while discarding ordinary abuse reports. The design therefore tried to test more than a narrowly whitelisted probe.

The validating person had to show control of the mailbox and an understanding of the procedure and policy. The first automatic acknowledgement to an incoming report was permitted, but the message then had to require manual intervention at some point. Mail could not be filtered. A reporter could not be forced to leave email and submit the allegation through a web form. The person completing validation was also expected to affirm regular monitoring, measures and response. Each of these additions shifted the evidential object. A successfully returned code proves that someone can receive two messages and operate the form.

It does not prove that a subsequent allegation is accurate, that a ticket has adequate evidence, that the reported customer is responsible, that a particular remedy is justified or that the sender deserves a substantive reply.

Sections 8.2 through 8.7 collectively built the crossing. The publication rule supplied the mandatory field. The availability and handling requirements prescribed the path by which reports could arrive. The validation provisions set the cadence and the attestation. The timing provisions transformed delay into temporary and then permanent invalidity. The escalation provisions introduced AFRINIC intermediation. The non-compliance language connected recurring failure with breach and procedures that could reach revocation. These were not interchangeable details.

Remove the behavioural and punitive layers and the directory still becomes more useful. Remove the contact field and no amount of enforcement language tells a reporter where to write.

The staff assessment published on the same date helps establish how the institution understood the text. Staff read Draft 1 as making abuse-c mandatory on directly issued inetnum, inet6num and aut-num objects, while leaving a choice for child records. It understood checks to occur on creation and at least quarterly, and it treated failed verification as a policy breach subject to the usual measures. Staff estimated at least one and a half months for development, testing and deployment. The assessment recorded no comments from legal counsel. That absence does not by itself decide the proposal’s validity, but it is significant to the design record: a mechanism capable of escalating a contact defect towards revocation-related procedures was assessed operationally without a recorded legal analysis of coercive jurisdiction.

The strongest case for Draft 1 deserves to be stated without caricature. Abuse complaints are time-sensitive. The cost of finding the right desk is not imaginary, particularly when address space passes through layers of customers and resellers. Security teams, network operators, incident responders and affected users benefit from a role address that survives staff turnover. A consistent field across registries can reduce misdirected reports. Periodic testing can identify mailboxes that silently died after a domain change or personnel departure. Inheritance lets a network use one competent central team.

An automatic acknowledgement can confirm receipt while a human later evaluates the evidence. Varying a test can discourage a holder from making the validation probe the only message that passes. A registry that publishes unreachable operational contacts is maintaining a poor directory.

That benign case supports the mandatory contact, not the rest of the machine. Objective deliverability asks a bounded question: can a message reach the designated role address? Draft 1 asked a different set of questions. Does the operator allow the registry’s preferred input channel? Has its filtering posture been judged acceptable? Will a person intervene manually? Does the operator take “measures”, and what does that word require? Must every report receive an answer even when it is duplicate, abusive, automated, malformed or unsupported? Those are decisions about the design and adequacy of an operational response system.

They cannot be inferred from the correctness of a registry record.

The exact wording also resists a convenient defence that the proposed duty was only to keep an email address current. A ban on filtering is not an address-format rule. A prohibition on requiring a web form is not a delivery test. Manual intervention is a staffing and process prescription. An assurance that measures are taken and reports receive a response reaches the substance of triage. Validation “whenever AFRINIC sees fit” introduces open-ended discretion beyond a predictable maintenance calendar. Intermediation places registry staff between reporter and operator.

Revocation-related follow-up turns the registry’s practical control over services into leverage. The five-day clock bound these pieces together, making behaviour visible through a contact field and attaching institutional consequences to failure.

The lifecycle after 12 August confirms that these stakes were recognised, but it must not be back-projected into Draft 1. Draft 2 appeared on 20 November 2018. At AFRINIC-29 later that month, participants disputed verified contacts, restrictions on MyAFRINIC, effects on voting, punishment and whether AFRINIC was assuming an “Internet Police” function. The co-chairs recorded no consensus and sent the proposal back for refinement. AFRINIC’s 2018 annual report later described mandatory abuse-c, validation and punitive measures including restrictions affecting portal and voting access. Those records are context from a later stage, after Draft 2 existed; they are not the verbatim content or legal effect of the 12 August instrument.

Nor may Draft 7 be folded into Draft 1. The version register records seven drafts, with the seventh submitted on 17 May 2021. Current material at the evidence cut-off describes that later version as ratified. Whatever wording, process, appeals or later status attached to Draft 7 belongs to its own history. It cannot make Draft 1 retroactively operative, supply legal authority missing from the first text, or prove that the original five-day mechanism caused an actual revocation. The precise object of analysis remains the first proposal and the institutional line it first tried to draw.

Read on its own terms, Draft 1 contained two designs occupying the same clauses. One was a registry-quality improvement: make one role contact easy to find, ensure that messages can reach it, and show when the record needs correction. The other was a conduct-compliance system: specify the operator’s intake architecture, demand assurances about action, revisit the operator on an elastic schedule, mediate complaints and connect failure with resource-sensitive procedures.

The first design answers “where can a report be sent?” The second begins to answer “has the network behaved acceptably?” A number registry has the records needed to answer the first question. It has neither the facts nor the public authority required to answer the second.