Qué cambió
No puede determinarse qué cambió en la política afrinic/afpub-2017-dns-001 porque la cronología verificada está vacía y no se suministraron versiones, modificaciones textuales, hitos ni fechas.
AFRINIC · Vigilancia de RIR
Consulta aquí el historial de cada propuesta: qué cambió, por qué fue relevante, quién defendió cada postura, cómo evolucionaron las posiciones, qué se decidió y dónde persisten las lagunas en la evidencia.
Hechos con fuentes
¿Quiénes marcaron realmente el debate?
Análisis de BTW
No puede determinarse qué cambió en la política afrinic/afpub-2017-dns-001 porque la cronología verificada está vacía y no se suministraron versiones, modificaciones textuales, hitos ni fechas.
No puede caracterizarse el objeto sustantivo del debate. El conjunto suministrado no contiene mensajes, argumentos, participantes ni posturas verificadas; por tanto, atribuir temas, intereses o conflictos excedería la evidencia.
No hay evidencia suficiente para distinguir la discusión de una decisión formal ni para afirmar adopción, rechazo, retirada, devolución para revisión o estado pendiente. Se registran 0 mensajes, 0 participantes de discusión, 0 actores formales y ninguna cronología o actuación decisoria.
La instantánea registra 0 mensajes, 0 participantes totales y 0 días activos. Las cuotas top-1, top-5 y top-10, el HHI y el número efectivo de participantes también son 0, pero estos valores no demuestran una participación desconcentrada: con un universo vacío, la concentración sustantiva no es evaluable. Tampoco puede identificarse un núcleo dominante, una periferia, recurrencia participativa o cambios de postura.
No puede identificarse un punto de bloqueo institucional, procedimental o deliberativo porque no se aportaron etapas del proceso, actores, intervenciones ni decisiones. El único cuello de botella verificable para esta interpretación es la insuficiencia del conjunto probatorio: faltan la cronología, el debate, las posturas y el acto decisorio.
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.Hechos con fuentes ↗
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.Hechos con fuentes ↗
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.Hechos con fuentes ↗
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.Hechos con fuentes ↗
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.Hechos con fuentes ↗
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.Hechos con fuentes ↗
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.Hechos con fuentes ↗
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.Hechos con fuentes ↗
La cobertura de la fuente está incompleta.
Parcial
Primera captura: 4 ago 2004
Última captura: 12 oct 2026