Summary

  • Draft 2 kept a proportionate technical outcome: remove a lame nameserver entry from the affected AFRINIC reverse zone, and delete the domain object only when no healthy nameserver remains. It did not remove IP allocations, alter forward DNS or reach minority-RIR and legacy-resource records excluded from scope.
  • The complete rewrite said that intent, actions and results were unchanged, but it removed Draft 1’s detailed checking, notification, archival and reinstatement language. That changed where the operative threshold was expressed, even if the stated destination stayed the same.
  • AFRINIC’s later monthly and daily implementations show that careful safeguards could be engineered. They do not show that those safeguards were part of Draft 2 in November 2017; they reveal the policy choices that the short text left to staff.
  • The sound answer is neither to preserve broken referrals nor to turn maintenance into membership discipline. A private registry should use reproducible evidence, multi-contact notice, a meaningful cure period, per-zone proportionality, durable history, rapid restoration and independent review, all firewalled from unrelated disputes.

L3 — What Draft 2 kept, and what it handed to staff

The problem begins with a small mismatch between a registry record and operational reality. A reverse-DNS parent zone contains a delegation to one or more nameservers. A resolver follows that direction because the parent record says that the listed server can answer for the child zone. If the server cannot be reached, does not respond, or is not authoritative for the zone, the referral is lame. The resolver has not merely received an honest statement that no data are available. It has been sent along an unproductive path and must spend queries and time discovering that the advertised route does not work.

That is why a lame delegation and no delegation are not operationally identical, although both may end without useful reverse-DNS data. With no delegation, the parent can produce a comparatively direct negative result. With a lame delegation, the parent promises a route that fails later. The latter can multiply queries, lengthen diagnosis and make an already absent answer more costly to obtain. A registry that removes a demonstrably unusable pointer can therefore make its record more truthful. The basic maintenance case is real, limited and technically coherent.

AFRINIC’s role in that maintenance is similarly specific. It administers registry records for Internet number resources and coordinates the relevant reverse-DNS delegation surface. It is a membership-based non-profit operating under Mauritian corporate law, not a public government for a geographical population. On this subject its useful capacity is that of a private technical bookkeeper: it can examine whether a nameserver listed in an AFRINIC reverse-zone record performs the function that the record claims, contact those responsible for the record, preserve evidence and make a bounded correction.

The registry entry coordinates operational reality; it does not create a general authority over the operator whose details appear in it.

Draft 1, submitted on 11 April 2017, tried to describe much of that correction process in policy language. It proposed periodic automated checking rather than an unexplained one-off judgement. A record would be flagged only after multiple failed checks. Notifications would go in parallel to the administrative, technical and zone contacts, with the possibility of using organisation or maintainer contacts as well. Unanswered notices would be repeated through a standardised, publicly documented notification protocol.

The remedial action was framed at the level of the affected zone: remove the lame server from that particular delegation, use an optional remark, retain a member-visible archive and permit restoration.

Those details matter because they turned the word “lame” from a label into an observable sequence. Periodicity described when the registry looked. Repetition distinguished a persistent failure from a transient outage. Parallel contact reduced the risk that one stale mailbox would become the sole gateway to cure. A documented notification protocol made the record of contact inspectable. Per-zone action limited the correction to the place where failure had actually been measured.

Archival and reinstatement recognised that measurement could be wrong, circumstances could change, or a corrected service might need to be returned quickly to the parent record.

The May 2017 staff assessment supplied a substantial benign reason to act. AFRINIC staff reported that roughly 44 per cent of the reverse space analysed on 12 May appeared lame. That was an institutional estimate, not an independent audit of every record, but it described more than an occasional housekeeping nuisance. The assessment also asked for discretion over notification, greater clarity about scope and removal of the explicit reinstatement clause. Those requests identified the fault line before Draft 2 appeared: how much of the operating procedure should bind staff, and how much should remain adjustable administration?

Draft 2 was published on 22 November 2017 as a complete rewrite for simplicity and clarity. It stated that the proposal’s intent, actions and results were unchanged. That statement deserves to be taken seriously. The rewrite did not announce a new objective, broaden the subject to address-resource recovery, or convert reverse-DNS maintenance into a disciplinary project. It retained the idea that lameness should be determined, responsible contacts should receive reasonable attempts at contact, and a lame nserver attribute should be removed. It also retained a remarks mechanism, deletion of the complete domain object where every nameserver entry was lame, and archive availability for a reasonable time.

But “unchanged” did not mean identical in institutional allocation. Draft 2 removed the background, terminology, explanation, impact, motivations and possible implementation detail that had made the proposed sequence visible. It no longer stated in binding policy how often tests would occur, how many failures would establish persistence, from how many points on the network the server would be queried, which contact roles must receive a notice, how many notices would be sent, what cure interval would follow, how a member could contest a false result, or how quickly a corrected delegation would be restored. The outcome remained recognisable.

The procedural envelope around the outcome became markedly thinner.

That change is not merely stylistic. A direction to make “reasonable” contact is different from naming the roles that must be contacted and documenting repeated attempts. A direction to keep an archive for a “reasonable” time is different from specifying what evidence the archive contains, who can see it, how long it lasts and whether it supports immediate reinstatement. A statement that a server determined to be lame must be removed is different from a published rule for reaching that determination. Concision can improve readability while simultaneously relocating consequential judgement.

The exact object of action must remain clear. A domain object in this setting represents an .arpa reverse-DNS delegation within AFRINIC’s registry. It is not an address allocation, a route announcement or the operator’s forward-DNS zone. One nserver attribute identifies one nameserver for the particular reverse zone. If that one server is persistently lame while another listed server remains healthy, the proportionate action is to remove the defective attribute, not the entire object. Only if every nameserver record in that object is lame does Draft 2’s outcome reach deletion of the object itself. Even then, the action concerns that reverse-zone delegation; it is not universal deletion of those nameservers from other zones.

Scope also constrained the proposal. The covered records were AFRINIC reverse-DNS records, excluding incoming records for minority-RIR space and legacy resources. That boundary prevents the proposal from being read as a general licence to tidy any DNS data AFRINIC might encounter. It dealt with a defined parent-zone surface for which AFRINIC performed registry coordination. It did not purport to alter forward DNS, to reach healthy nameservers elsewhere, or to determine ownership of the underlying number resources.

Draft 2 linked to a sample implementation guideline, but expressly said that the guideline was not part of the policy and might not reflect the final implementation by staff. That caveat is central. The link could help readers imagine how the short outcome might work, yet it could not supply binding content that the policy itself had discarded. A person assessing the rule on 22 November could not treat the sample as a guaranteed test protocol, notice schedule, cure period or restoration promise. The practical rule would emerge only when staff selected and operated those variables.

The later process should not be projected backwards. The authors presented Draft 2 remotely at AFRINIC-27 on 30 November, where the meeting summary described the intent as unchanged, noted the claimed authority problem in the registry, distinguished staff implementation and moved the proposal to Last Call. A 15-calendar-day Last Call ran from 1 to 16 December. The mailing list recorded support, and later recorded a disagreement over whether the co-chair report adequately represented the discussion and Last Call feedback. One participant challenged the report; another defended the process.

The available evidence establishes that the disagreement occurred, not that an adjudicated process defect was proved.

Nor did publication itself amount to adoption or operation. The Board ratified Draft 2 on 21 March 2018 through Resolution 201803.395, with its minutes recording a conflict discussion and the chief executive’s recusal. The consolidated policy manual incorporated section 10.7 on 22 August 2018. Deployment began later in September. These are distinct institutional acts.

Draft publication, a private meeting process, Board ratification, manual integration and technical implementation cannot be compressed into a single event, because each answers a different question: what text was proposed, what internal consensus was declared, what the corporate Board ratified, what appeared in the manual, and what staff eventually ran.

The distinction also matters for authority. Official records are strong evidence of what AFRINIC wrote, reported, ratified and implemented. They cannot establish, simply through AFRINIC’s own language, that a service region is a sovereign public or that a policy meeting is a legislature. Co-chair and Board acts remain decisions within a private institutional arrangement. That does not make the decisions meaningless.

It means their legitimacy must rest on the narrow technical task, contractual and organisational accountability, reproducible operation and the ability of affected operators to examine and correct the registry action—not on an imagined public-law mandate.

Read in that frame, Draft 2 preserved a sensible destination but weakened the map visible to the people who had to travel there. A broken pointer could be removed. A whole reverse-zone object could disappear only when every listed server failed the relevant test. Records outside the defined AFRINIC reverse-DNS scope were not pulled in. Yet the rewrite no longer fixed the evidential and temporal conditions that converted a passing failure into a removal decision. Those conditions did not cease to exist. They moved from the face of policy into staff’s implementation choices.