AFRINIC · RIR Watchdog
Start here for the proposal-by-proposal record: what changed, why it mattered, who argued for what, how positions evolved, what was decided, and where the evidence still has gaps.
Source facts
Who actually shaped the debate?
BTW Analysis
No policy evolution can be established from the supplied verified facts. The policy chronology and participant stance timelines are empty, and the participation snapshot records no messages, participants, active days, or stance transitions from which changes in wording, support, opposition, or status could be reconstructed.
The substance of the debate cannot be identified because no messages, arguments, participant stances, or dated policy revisions are supplied. The empty record must not be interpreted as evidence that no debate occurred outside the measured source.
Neither a discussion process nor a decision outcome is documented in the supplied facts. Zero recorded formal actors and zero observed discussion do not prove that no decision occurred; they only show that this extract cannot identify adoption, rejection, withdrawal, implementation, a decision-maker, or a final policy text.
The snapshot contains zero messages, zero discussion participants, zero formal actors, zero total participants, and zero active days. Consequently, the zero top-message shares, HHI, effective-participant count, and core-participant counts are non-diagnostic and do not establish equal influence, broad inclusion, or unconcentrated participation.
No procedural or institutional chokepoint can be identified. There are no recorded proposers, discussants, formal actors, decisions, or stance transitions through which influence or decision power could be traced. The principal analytical chokepoint is the absence of captured chronology, discussion, roles, and decision evidence.
Monitoring and notification detail moves out of the policy text · Draft 1 required automated periodic checks and multiple lameness failures before escalation. Draft 2 replaces that detailed monitoring process with a requirement to establish lameness and make reasonable contact attempts before removing an nserver attribute. Its separately linked sample manual remains implementation guidance, explicitly outside the policy. The shorter rule preserves the prerequisites for removal without prescribing the former check sequence.
This periodic checking should be automated. The checks should be relatively frequent, but not so frequent as to cause any operational impact to either AFRINIC systems or the global DNS. If a nameserver fails a check for the first time, this is initially just recorded. Only after failing multiple lameness checks, should a nameserver be flagged for further action.Source facts ↗
10.7 Removal of ‘Lame’ Delegations Once a given ‘nserver’ attribute has been determined to be lame for a given domain, and reasonable attempts have been made to contact the responsible person(s), the nserver attribute must then be removed from the given domain object.Source facts ↗
Notification method left to implementation · Draft 1 specified parallel attempts to reach named contact classes, repeated unanswered communications, and a publicly documented contact procedure. Draft 2 retains reasonable attempts to reach the responsible persons but omits those detailed notification instructions. That changes how prescriptive the policy is; it does not remove the duty to try to make contact before deletion.
All of the "admin-c", "tech-c" and "zone-c" contacts should be tried in parallel. In addition, contact information may be extracted from associated "org" and/or "mnt-by" attributes when appropriate. Unanswered notification communications should also be re-tried more than once before moving on to further actions. The communication frequency, communication method(s) and number of attempts should be standardised and publicly documented.Source facts ↗
Once a given ‘nserver’ attribute has been determined to be lame for a given domain, and reasonable attempts have been made to contact the responsible person(s), the nserver attribute must then be removed from the given domain object.Source facts ↗
Recording removal and retaining history · Draft 2 changes the optional remarks line into a recommendation that a removal be recorded. It retains removal of the whole domain object when every nameserver is lame, but its archival wording covers removed domain objects rather than explicitly naming both nameservers and domain objects; access is described as available as necessary rather than specifically for member information. This narrows the explicit archival description without establishing that nameserver history may be discarded.
An optional "remarks" line may be added to the "domain" record in the database. Should a given domain have all it's nameserver's identified as lame, and thus removed, it must then also be removed from the database, due to the "nserver" attribute being mandatory for "domain" objects. Historical information about removed nameservers and domain objects should be archived for a reasonable amount of time and made available to the member for informational purpose.Source facts ↗
A ‘remarks’ line should be added to the domain object in the database recording this. In the event all nameserver records are lame for a given delegation, the domain object would be removed in its entirety. Historical information about removed domain objects should be archived for a reasonable amount of time and made available as necessary.Source facts ↗
Explicit reinstatement clause no longer included · Draft 1 expressly described restoring a fixed or replacement nameserver through the ordinary new-delegation process. Draft 2 omits that standalone reinstatement clause and identifies the sample operations manual as non-binding guidance. The omission removes an explicit policy description of restoration; it does not prove that restoration is prohibited or that the sample manual defines a mandatory replacement procedure.
10.7.4 Re-instatement Once nameservers are fixed, or alternate nameservers are available for a given reverse DNS zone, the responsible person(s) would add delegation to them in the same way as a new delegation is done for a new IP assignment or allocation.Source facts ↗
3.2 Sample Implementation Guideline A sample operational manual is available online as a suggested guideline to AFRINIC staff. Please note that this is a sample by the authors for a suggested implementation, and not part of the policy. It does not necessarily reflect a final implementation by AFRINIC staff.Source facts ↗
Source coverage is incomplete.
Partial
Earliest captured: Aug 4, 2004
Latest captured: Oct 12, 2026
