Summary

  • Draft 1 conditioned a new reverse delegation on the presence of a registered assignment or sub-allocation, asked AFRINIC to remind existing LIRs whose records lacked those objects, and categorically protected reverse delegations approved before ratification from removal.
  • Draft 2 made the database test more specific: for a /24 reverse delegation, at least one assignment or sub-allocation in that /24 would be sufficient, and the whole /24 did not have to be shown as assigned.
  • Draft 2 also inserted a twelve-month period after a reminder before AFRINIC could consider removing reverse delegation, a meaningful improvement in time to correct a record but not due process by itself.
  • The same revision removed Draft 1’s grandfathering and permitted removal from any LIR allocation after twelve months, widening the population exposed to withdrawal of the parent-zone service.
  • Reverse-DNS removal would not revoke an address allocation or stop BGP routing, but it could impair mail acceptance and reputation, diagnostics, naming continuity and downstream customer operations.
  • AFRINIC’s control of the database and reverse-DNS machinery makes it a private bookkeeper and technical coordinator, not a sovereign, regulator, police force, punishment body, confiscator or adjudicator. A service dependency cannot create powers the institution does not otherwise possess.
  • AFRINIC’s archive index currently places both D1 and D2 item pages under 23 April 2012, but D2’s own proposal history identifies 30 November 2012 as its submission date, one day after AFRINIC-17 still discussed D1. This analysis therefore discloses the index anomaly and uses 30 November as the substantive D2 date.

Three edits, one institutional question

The important event is small enough to miss in a broad history. In AFPUB-2012-DNS-001-DRAFT-01, submitted by Tim McGinnis on 10 April 2012, AFRINIC was asked to connect the availability of reverse delegation to the existence of assignment or sub-allocation objects in its database. New reverse delegation would depend on an appropriately registered object. Existing LIRs with reverse DNS but no such objects would receive a reminder, envisaged through MyAFRINIC and email. But D1 drew an absolute line around delegations approved before ratification: AFRINIC would not remove them.

Only later allocations would be affected by the removal path contemplated in the proposal.

D2 moved three elements of that design. It defined what sufficiency meant for a /24: at least one assignment or sub-allocation registered for that /24, without requiring the entire /24 to be assigned. It created a twelve-month interval from reminder to possible action. And it replaced D1’s categorical protection of older delegations with wording that permitted AFRINIC, after those twelve months, to remove reverse delegation from any LIR allocation.

Those movements do not all point in the same direction. The first narrowed ambiguity. The second slowed the clock. The third expanded exposure. It would therefore be incomplete to describe D2 simply as tougher or softer than D1. D2 was more specific about the minimum database object, more patient about correction, and more expansive about which existing services could ultimately be withdrawn.

That combination raises the central institutional question: did a better-calibrated record rule justify turning an existing technical service into leverage over every covered allocation? The documentary record supports a qualified answer. The /24 threshold and twelve-month interval were real continuity-relevant improvements. Yet neither transformed AFRINIC into a public enforcement authority, and neither supplied the safeguards needed when a private coordinator’s record-maintenance process can reach a live service used by networks and customers.

The date on the shelf is not the date in the file

Chronology matters because the redline responded to an immediate discussion, not to an event that occurred before it. AFRINIC’s current 2012 archive index places both D1 and D2 item pages under a 23 April label. Read alone, that index could suggest that the second draft existed before AFRINIC-16 in May. The proposal history on D2’s own page says otherwise: it identifies the second draft as submitted on 30 November 2012. AFRINIC-17’s minutes, dated 29 November, still identify the proposal as D1 and record questions that D2’s wording then addressed.

The archive therefore contains an anomaly that cannot responsibly be smoothed away. The 23 April label is part of the official archive and should be reported as such, but it is not used here as D2’s substantive publication date. The stronger internal sequence is D1 on 10 April, discussion of D1 at AFRINIC-16 on 18 May, continued discussion under the D1 identifier at AFRINIC-17 on 29 November, and D2’s recorded submission on 30 November. That is why this article treats 30 November as the operative date of the revision.

The distinction is not clerical fussiness. If D2 were falsely placed in April, its one-assignment-per-/24 language could be mistaken for the premise of the May discussion rather than a later refinement. The revision would also appear detached from the November question about whether one assignment should make reverse DNS available and whether a percentage threshold should be stated. Using the proposal history date preserves the direction of influence that the documents can support: the meeting exposed a design problem; the next published text addressed it.

It does not prove that any one participant dictated the change or that the discussion represented a public mandate.

Official pages and minutes establish words, dates as displayed, attributed statements and recorded procedural results. They do not establish sovereign authority, lawful mandate or private motive. The chronology can show that a question preceded an edit. It cannot turn a meeting room into a legislature or an internal consensus process into popular sovereignty.

D1’s blunt condition and protected installed base

D1 began from a recognizable bookkeeping problem. Reverse delegation was available in relation to address space, while assignment or sub-allocation information could be absent from AFRINIC’s database. Its section 3.1 proposed that a new reverse delegation would not be made unless an assignment or sub-allocation had been registered for the address space. The rule connected two registry functions: the public record of downstream use and the parent-zone delegation that makes reverse lookup possible.

The draft did not yet say that one object in each /24 would suffice. “An assignment or sub-allocation” established a condition, but not the later zone-level threshold. That ambiguity mattered. If a registry required a fully granular utilisation picture before providing reverse service, operators could face an administratively large obligation. If a single record anywhere under a much larger allocation were enough, the connection between the database condition and the delegated zone could become weak. The choice of unit—allocation, zone or individual assignment—would determine both the burden and the informational value of compliance.

For existing LIRs, D1 envisaged contact through MyAFRINIC and email. The reminder was a request to register assignments or sub-allocations. Implementation details were left to staff. The text did not establish a fixed cure period, prove that a notice had been received, create an independent appeal or specify how a contested database condition would be checked.

But D1’s section 3.3 also limited the service risk. Reverse delegations approved before ratification would not be removed. Whatever the defects of notice or validation, the installed base received categorical protection in the proposal. That grandfathering reduced the possibility that a record-cleaning initiative would break an existing reverse-DNS dependency. It also created an asymmetry: older delegations could remain even when the database lacked the desired objects, while later allocations would face a different rule.

The asymmetry may have made the record policy less uniform, but it served a continuity function. Existing services can carry dependencies that are not visible from the registry record itself. A network may route without reverse DNS, yet mail systems, reputation checks, diagnostics and customer processes may rely on reverse mappings. D1’s grandfathering prevented the proposal from treating those installed dependencies as expendable solely because a database object was missing.

What the two meetings actually establish

The AFRINIC-16 report records D1’s discussion on 18 May 2012. It attributes to the author an estimate that close to 40 percent of ISPs had not registered any assignment. It also records recognition of the importance of reverse DNS and the consequences of its unavailability, alongside questions about effectiveness, staff burden and network scanning. The meeting reached no consensus and returned the proposal to the mailing list.

The approximate 40 percent figure gives the proposal its stated scale, but not a verified measurement. The minutes do not publish the underlying dataset, denominator, observation date or method. “Close to 40%” must therefore remain an attributed meeting statement, not a database-wide fact established by independent analysis. Nor does the absence of a registered assignment prove that addresses were unused, unlawfully held, abandoned or outside the registrant’s control. It proves, at most, the record discrepancy the query detected.

That distinction is fundamental. A bookkeeper can identify that a ledger lacks an expected entry. The missing entry may warrant a request for correction. It does not resolve every fact about the underlying activity. Treating a record gap as proof of misuse would convert an evidentiary shortcut into judgment. The available record gives no basis for that conversion.

At AFRINIC-17 on 29 November, the item still carried the D1 identifier. The minutes record a question about whether one registered assignment should be enough to make reverse DNS available and support for stating a percentage threshold. Again, the meeting recorded no consensus and sent the proposal back to the list. The comments illuminate the design tension: the policy needed a condition specific enough to administer without demanding that an entire address block be shown as assigned.

These discussions are evidence of institutional deliberation, not a grant of public power. Participants and co-chairs were engaged in an internal coordination process. Their questions can improve a technical rule. Their participation does not make them legislators, and a no-consensus result does not confer authority by implication. The relevant achievement of the November exchange is narrower: it placed the sufficiency problem on the record immediately before D2 supplied an answer.

D2’s precise threshold

D2 section 3.1 stated that, for a /24 reverse delegation, at least one assignment or sub-allocation had to be registered for that /24. It further clarified that the entire /24 did not have to be assigned. This was a material improvement in administrability. It aligned the record test with the reverse zone under consideration and rejected the most demanding reading of D1.

The threshold was modest. One object could open the service condition for the /24. It was not a certification that every address in the zone was in use, that every downstream customer appeared in the database or that the database contained a complete utilisation picture. It should be described as a sufficiency threshold for a particular registry service, not a comprehensive audit.

That modesty cuts both ways. It reduced the compliance burden and made a blanket demand for complete assignment data less likely. But it also weakened any claim that the service condition was a searching enforcement device. If one registered object was enough, the rule’s direct purpose was better understood as obtaining a minimum link in the registry ledger. The proposal’s own use of the phrase “enforcement mechanism” reported how it framed the connection; it did not prove that AFRINIC possessed lawful enforcement authority.

AFRINIC’s legitimate institutional interest was narrower and more concrete. As a nonprofit, member-based regional Internet registry, it coordinates number-resource records and related services. A private registry can seek accurate records, preserve uniqueness, verify that an applicant is entitled to request a change and operate reverse DNS under objective service conditions. None of those tasks makes it a government, regulator, police force, prosecutor, punishment body, confiscator or adjudicator. Technical control over the parent zone creates capacity to act, not sovereign permission to punish.

Twelve months: valuable time, incomplete protection

D2 section 3.2 supplied something D1 lacked: a defined interval. An affected LIR would have twelve months from the reminder to register assignments or sub-allocations. For record remediation, a year is significant. It allows an organisation to identify missing objects, reconstruct internal information and use the registry system without an immediate threat to service continuity.

That improvement should not be minimized. Time can separate a correctable administrative defect from abrupt operational harm. A long remediation window also reduces the chance that a temporary staff absence or short delay will immediately affect reverse service.

But duration is not due process. D2 did not state how AFRINIC would prove delivery of the reminder, whether notice would be repeated, how precisely the missing object would be identified, who would verify a cure, how a disputed record would be reviewed, or what would happen if service withdrawal endangered dependent customers. A twelve-month clock cannot protect a party that never receives a specific notice, cannot resolve an erroneous database assessment and cannot itself provide independent review.

The difference between time and process is especially important in a service-dependent system. The party responding to a reminder must know what is missing and how to cure it. The registry must validate the correction against a published standard. Before any service-affecting step, a contested finding requires review outside the same operational chain that identified the discrepancy. Continuity exceptions must exist for cases in which the cost to networks and customers would be disproportionate to the bookkeeping problem. D2’s published text states none of those protections.

The deleted protection

The most consequential D2 change appears in section 3.3. D1 said AFRINIC would not remove reverse delegation from allocations approved before ratification. D2 replaced that categorical grandfathering with permission to remove reverse delegation from any LIR allocation beginning twelve months after the reminder.

This is the redline’s hinge. A reader focused only on the one-object threshold and the twelve-month period might see a more proportionate draft. A reader focused only on the deletion of grandfathering might see expansion. Both readings capture part of the change. D2 narrowed the immediate evidence trigger and slowed the path, while widening the population that could eventually face withdrawal.

The word “may” is relevant but not sufficient. Discretion is not the same as automatic removal, and the draft did not compel AFRINIC to withdraw every delegation after twelve months. Yet discretionary power without published criteria can create its own uncertainty. The source does not state what staff would weigh, whether similarly situated LIRs would receive the same treatment, or how continuity harm would influence a decision. Those unknowns must remain unknown; they cannot be filled with assumptions about benevolent restraint or aggressive enforcement.

Nor should “remove reverse delegation” be inflated into something the text did not say. It is not revocation of an address allocation. It is not confiscation of number resources. It does not itself send a BGP withdrawal or stop routing. The direct action would be withdrawal of AFRINIC’s parent-zone reverse-DNS service. That boundary is technically and institutionally exact.

But precision about the mechanism does not make it trivial. Reverse DNS can affect whether mail is accepted or distrusted, how network reputation is assessed, whether operators can diagnose a problem and whether customer systems retain expected naming behaviour. Routing continuity and service continuity are related but not identical. A packet may still travel while a mail flow, diagnostic practice or customer process degrades. The absence of evidence for a specific 2012 outage does not erase the impact channel; it limits the claim to a credible mechanism rather than a quantified harm.

Coordination must remain coordination

The redline illustrates a recurring governance error: confusing control of infrastructure with authority over those who depend on it. AFRINIC operated the relevant database and parent-zone service. That operational position allowed it to condition a request, send a reminder and technically remove a delegation. Yet the fact that an institution can do something does not establish that it may use the act as punishment or final judgment.

Under the controlling institutional doctrine, AFRINIC is a private bookkeeper and technical coordinator. It can maintain an accurate ledger and administer a bounded service. It cannot decide, merely from a missing assignment object, that an LIR has abused resources, abandoned them, lost control or forfeited entitlement. It cannot convert a record discrepancy into a fine, penalty, confiscation or police measure. It cannot make itself the final adjudicator of legality or ownership.

That boundary also clarifies the right response to D2. The proposal did not need to be condemned for caring about database quality. Accurate assignment and sub-allocation records can support coordination. A registry can require objective information for a new or changed delegation. The problem arises when the correction process reaches an already operating service without adequate verification, review and continuity safeguards.

Reverse-DNS disablement must therefore never be normalized as punishment. At most, D2 proposed withdrawal of a registry-operated service after a record condition remained unsatisfied. Even that bounded description demands scrutiny because service withdrawal can impose costs on parties other than the record maintainer. The draft’s narrow administrative aim did not erase the need to protect the network and its customers.

A mixed answer to the continuity question

Did D2 answer continuity concerns? It answered some of them. The /24 threshold reduced uncertainty about how much registration was enough. The twelve-month interval reduced the risk of sudden action. These were concrete improvements over D1’s open-ended condition and unspecified cure timing.

Did D2 create a safer overall mechanism? Not clearly. It exchanged D1’s absolute protection for existing delegations for a timed, discretionary path that reached every LIR allocation. The installed base moved from categorical exclusion to possible exposure. The draft did not pair that expansion with proof of notice, an explicit correction protocol, independent review or an exception for severe downstream consequences.

The institutional balance is therefore asymmetrical. D2 improved the front end of the rule—the record threshold and the time to respond—while enlarging the back end—the range of services that could be withdrawn. A continuity-first design would preserve the installed service while correcting the ledger, except under a separately justified, narrowly reviewed technical necessity. D2 did not state that design.

The proper conclusion remains narrow. The redline was neither meaningless nor a grant of enforcement authority. It was a serious attempt to make a registry condition administrable, coupled with an expansion of operational leverage. Its value lies in revealing exactly where coordination can slide into coercion: not when the private bookkeeper asks for an accurate entry, but when access to an important service becomes the means of compelling it without the protections appropriate to the resulting harm.