Ce qui a changé
Aucun changement de politique ne peut être établi à partir des faits fournis. La chronologie est vide et aucun texte initial, amendement, texte final, événement procédural ou acte de mise en œuvre n'est documenté.
AFRINIC · Veille des RIR
Commencez ici pour consulter l’historique, proposition par proposition : ce qui a changé, pourquoi cela comptait, qui a défendu quoi, comment les positions ont évolué, ce qui a été décidé et quelles lacunes subsistent dans les preuves.
Faits sourcés
Qui a réellement façonné le débat ?
Analyse BTW
Aucun changement de politique ne peut être établi à partir des faits fournis. La chronologie est vide et aucun texte initial, amendement, texte final, événement procédural ou acte de mise en œuvre n'est documenté.
La substance du débat ne peut pas être déterminée. Aucun message, argument, participant, camp, position ou transition de position n'est enregistré; il n'est donc pas possible d'identifier un désaccord de fond, un enjeu procédural ou un compromis.
Ni discussion observable ni décision formelle ne sont documentées. Les métriques indiquent zéro message, zéro jour actif, zéro participant et zéro acteur formel, tandis que la chronologie et les trajectoires de position sont vides. Il est donc impossible de comparer une décision à des positions exprimées ou de déterminer si une issue a résulté d'un consensus, d'un arbitrage ou d'un autre mécanisme.
Les parts des principaux contributeurs, le HHI, le nombre effectif de participants et les noyaux à 50 % et 80 % sont tous nuls parce qu'aucun message ni participant n'est recensé. Ces valeurs décrivent l'absence d'une distribution mesurable et ne permettent pas de conclure que la participation était concentrée, dispersée ou inclusive.
Aucun point de blocage procédural, institutionnel ou argumentatif ne peut être identifié. Aucun message, acteur formel, participant associé à une position, changement de position ou acte décisionnel n'est enregistré. Le principal obstacle à l'interprétation est donc l'absence de chronologie, de contenu de débat et de décision dans le dossier fourni.
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.Faits sourcés ↗
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.Faits sourcés ↗
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.Faits sourcés ↗
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.Faits sourcés ↗
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.Faits sourcés ↗
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.Faits sourcés ↗
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.Faits sourcés ↗
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.Faits sourcés ↗
La couverture de la source est incomplète.
Partielle
Première capture: 4 août 2004
Dernière capture: 11 oct. 2026