Resumo

  • A DRAFT02, apresentada pela AFRINIC em 25 de setembro de 2026, diz que testes automatizados podem apontar sinais possíveis de descumprimento; o pessoal deve verificar as informações antes de uma investigação ou medida baseada no RSA ou no estatuto.
  • Em relação à DRAFT01, o resultado automático deixa de ser uma conclusão de não conformidade e passa a ser um indício para análise humana.
  • Um mapa versionado entre política e teste deve mostrar a regra aplicável, sua vigência, o universo de recursos, a fonte de dados e a versão do teste — e também o que o alerta não comprova.
  • A proposta continua em discussão. Os registros públicos não mostram painel em operação, aviso a membro, constatação de infração ou sanção.

Um dado observado não determina sozinho o que a política exige

Considere um aviso de que um registro não corresponde a uma condição esperada. Um programa pode ter lido um campo de contato, comparado um objeto de rota ou confrontado uma alocação com uma regra. A comparação pode ser reproduzida. Ela não prova, por si só, que aquela política se aplica ao membro, que o registro está atualizado ou que houve violação de uma obrigação.

Essa é a fronteira que aparece no projeto de Policy Compliance Dashboard da AFRINIC, AFPUB-2026-GEN-002-DRAFT02. A versão de 25 de setembro prioriza o que pode ser medido da forma mais objetiva possível e fala em sinais possíveis de descumprimento. O texto também diz que o painel não decide o caso: o pessoal precisa verificar as informações geradas por testes automatizados. Se houver evidência que sugira descumprimento, a proposta prevê uma investigação mais completa e possíveis medidas sob o RSA ou o estatuto.

Essas frases não descrevem um sistema já implantado. A lista atual de propostas ainda classifica a DRAFT02 como em discussão. O foco aqui é o limite de desenho previsto no texto e a trilha de evidência necessária caso a AFRINIC venha a construí-lo.

A DRAFT02 altera o significado de um resultado automático

A DRAFT01 arquivada usava termos mais conclusivos. Previa notificações assim que uma não conformidade fosse detectada, lembretes, um período de persistência definido pelo pessoal, procedimentos posteriores e regras a elaborar para suspender serviços, revogar recursos ou encerrar a associação. Também propunha uma exceção do Conselho para alguns casos de infraestrutura crítica ou situações excepcionais.

A DRAFT02 não é apenas a mesma proposta sem um prazo. Ela retira as cláusulas separadas sobre duração da persistência e regras de sanção a serem definidas depois pelo pessoal. Em seu lugar, explicita que a conformidade não pode ser medida com objetividade total e que os testes podem somente sugerir sinais possíveis. A verificação humana agora aparece no próprio texto proposto. A possibilidade de medidas adicionais sob o RSA ou o estatuto permanece, inclusive suspensão de serviço, revogação ou encerramento da associação.

A revisão muda, portanto, o papel atribuído ao software. O texto anterior partia de um estado detectado e chamado de não conformidade. O atual parte de um sinal que pode estar errado, incompleto ou fora do escopo da regra. A conferência do pessoal deve fazer a ligação entre as etapas. Para ser confiável, quem confere precisa ver a base do teste, e o membro precisa conseguir reconstruir o mesmo resultado.

A versão da política precisa acompanhar a prova

A proposta diz que a automação deve evoluir junto com o Manual Consolidado de Políticas (CPM). Isso não é só uma tarefa de manutenção. Um teste que refletia corretamente a regra ontem pode classificar um recurso de forma errada após uma mudança ou aplicar um critério antes da data de vigência. Um indicador verde ou vermelho sem a versão da regra esconde essa diferença.

A avaliação de impacto anexada à DRAFT01 citava exemplos como precisão dos contatos, validade do contato para abuso, consistência de objetos de rota, cobertura RPKI quando aplicável e requisitos de DNS reverso. São exemplos da avaliação da versão anterior, não um catálogo final da DRAFT02 nem prova de que os controles já estejam implantados. Eles mostram por que “automático” não quer dizer “autoexplicativo”. A ausência de um campo pode ser observável; saber se a regra aplicável exige esse campo para aquele recurso é outra pergunta. Uma comparação de rotas ou RPKI também depende da fonte, do horário observado e do escopo.

Cada verificação deveria ligar dois registros. O primeiro é o mapa da regra: identificador, versão, data de vigência, classe de recurso e condições de aplicação. O segundo é o recibo do teste: fonte, hora da consulta, transformação, versão do teste, resultado e limitações conhecidas. Assim, o pessoal pode voltar ao dado original e explicar por que a regra se aplica — ou por que o aviso deve ser retirado. O membro pode examinar a mesma base sem acessar informações operacionais privadas de terceiros.

Essa é uma recomendação editorial, não um recurso anunciado pela AFRINIC. A DRAFT02 não define catálogo completo, método de versionamento, métrica de precisão nem registro de como o pessoal concluiu a revisão. Mas, se o resultado automático só é um indício possível até ser conferido, a regra e o dado que serão conferidos precisam estar visíveis.

Dados, sinais e medidas são afirmações distintas

Uma trilha verificável deveria separar pelo menos quatro estados: o dado observado no registro ou na rede; a comparação automática que gera um possível indício; a conferência do pessoal sobre a fonte e a regra; e, em separado, qualquer medida permitida pelo RSA ou pelo estatuto. Não são sinônimos. Um rótulo do painel não deveria transformar silenciosamente o primeiro estado no último.

A separação protege os dois lados. O membro pode corrigir o cadastro ou explicar por que a regra não se aplica. O pessoal pode distinguir problema de qualidade de dados de interpretação de política. A AFRINIC pode documentar o que sustentaria uma investigação posterior. Se o teste estiver errado, o aviso pode ser corrigido sem deixar uma classificação inexplicável no histórico do membro.

O canal econômico é prospectivo, mas está descrito na própria proposta: pedidos futuros, serviços e a associação poderiam ser afetados sob o RSA. Uma classificação enganosa poderia consumir tempo de um operador ou pesar em uma análise posterior; um aviso correto poderia ajudar a resolver um problema cedo. As fontes públicas não demonstram nenhum desses resultados hoje. Elas permitem perguntar: como distinguir um aviso útil de uma verificação desatualizada ou aplicada fora do contexto?

O histórico mostra uma revisão, não o desfecho da DRAFT02

A AFRINIC-37 discutiu a DRAFT01 em 24 de junho. A ata registra que os copresidentes não identificaram consenso aproximado e devolveram aquela versão à lista de discussão; um comunicado de agosto repete o resultado. A DRAFT02 foi apresentada em 25 de setembro, e seu histórico diz que incorporou discussões no RPD e uma avaliação de impacto. O resultado de junho diz respeito à DRAFT01, não decide a versão atual.

A versão revisada restringe o que a automação deve decidir e inclui a verificação humana. É um limite probatório mais claro, mas não uma salvaguarda já testada em operação. O próximo passo deveria publicar o catálogo de testes junto com a política: versão, vigência, escopo, fonte, lógica, limitações e registro da conferência. Assim, membros e operadores poderiam examinar o mecanismo antes de tratar um aviso como algo além de uma pista.

Fontes e escopo. A DRAFT02 e a lista atual de propostas estabelecem o texto e o status. A DRAFT01 arquivada e sua avaliação de impacto fornecem a redação anterior e exemplos de verificações. A ata da AFRINIC-37 e o comunicado dos copresidentes de 12 de agosto registram o retorno da DRAFT01 à lista. Nenhuma dessas fontes comprova implantação ou resultado referente a um membro.