O que mudou
Não é possível determinar o que mudou na política afrinic/afpub-2017-dns-001, pois a cronologia verificada está vazia e não foram fornecidas versões, alterações textuais, datas ou justificativas.
AFRINIC · Monitoramento de RIR
Comece aqui pelo registro de cada proposta: o que mudou, por que isso foi relevante, quem defendeu cada posição, como as posições evoluíram, o que foi decidido e onde ainda há lacunas nas evidências.
Fatos com fonte
Quem realmente moldou o debate?
Análise BTW
Não é possível determinar o que mudou na política afrinic/afpub-2017-dns-001, pois a cronologia verificada está vazia e não foram fornecidas versões, alterações textuais, datas ou justificativas.
Não há base factual para caracterizar o objeto substantivo do debate. A amostra contém zero mensagens, zero participantes e nenhuma posição registrada.
Não foi fornecido registro de discussão nem de decisão formal. Portanto, não é possível determinar se a política foi adotada, rejeitada, retirada, abandonada, substituída ou permaneceu pendente, nem comparar eventual decisão com posições da comunidade.
As métricas registram zero mensagens, zero participantes de discussão, zero atores formais, zero participantes totais e zero dias ativos. Top-1, top-5, top-10 e HHI iguais a zero não demonstram participação desconcentrada; na ausência de mensagens e participantes, esses indicadores são não informativos sobre concentração de voz ou influência. Também não foi identificado núcleo ativo, participação recorrente, posições ou transições de posição.
Nenhum ponto de estrangulamento decisório, controle de agenda ou concentração de influência pode ser identificado. A inexistência de atividade observável na amostra impede atribuir poder de bloqueio, encaminhamento ou decisão a qualquer participante, autor, ator formal ou órgão.
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
A cobertura da fonte está incompleta.
Parcial
Primeiro registro: 4 de ago. de 2004
Último registro: 11 de out. de 2026