Resumo

  • A ata da AFRINIC-37 relaciona MyAFRINIC v2 à implementação integral de ROAs AS0, ao sistema técnico de transferências e à implementação interna da política de contato de abuso; uma avaliação separada coloca depois do portal uma proposta AS-SET ainda em Last Call.
  • Os quatro caminhos não são módulos equivalentes. Três políticas foram ratificadas, a quarta não; elas passam por RPKI, procedimentos com outros RIRs, validação interna, WHOIS e IRR.
  • Um portal no ar prova disponibilidade de plataforma, não execução de política. Cada caminho precisa de seu próprio registro de dependência e aceite, com texto, versão, baseline, testes, definição parcial/integral, ativação e correção.
  • Uma base compartilhada pode reduzir trabalho duplicado e inconsistência legada. O risco nasce quando uma única notícia de lançamento apaga as diferenças entre testado, parcial, tecnicamente pendente, proceduralmente em curso e ainda não ratificado.

Em projetos de software, uma data costuma encerrar a conversa. O produto foi lançado, a versão entrou em beta ou a migração terminou. Em política institucional, a data abre outra conversa. É preciso saber qual texto passou a governar, em que sistema, para quais casos, por decisão de quem, e como um resultado incorreto será consertado.

MyAFRINIC v2 tornou essa diferença especialmente importante para a AFRINIC. Os documentos oficiais verificados colocam quatro trajetórias atrás da mesma reforma do portal de membros. Isso é uma escolha de arquitetura e de alocação de recursos. Não é, por si só, um estado regulatório.

Uma trajetória trata de ROAs AS0 para espaço de endereços não alocado ou não designado. Outra trata da política de transferências, inclusive entre registros. A terceira trata da validação de contatos de abuso. A quarta propõe nomes hierárquicos para novos AS-SETs. As três primeiras estão ratificadas no material conferido. A quarta aparecia em Last Call.

Se todas forem resumidas como “dependentes do portal”, a frase explica a fila, mas perde o objeto. A prova de um AS0 não é a prova de uma transferência. A prova de uma mensagem de validação não é a prova de que todos os caminhos de criação de AS-SET respeitam uma regra. O artigo deve, portanto, separar as quatro catracas: qual condição cada política precisa atravessar antes de ser chamada de operacional?

O marco comum ainda não é uma linha de chegada

A ata da AFRINIC-37, reunião de 24 de junho de 2026, registra que o desenvolvimento de MyAFRINIC v2 começou em 2020. Restrições orçamentárias e de recursos por vários anos atrasaram o trabalho; o projeto foi retomado e, naquela data, era esperado para o fim de 2026. Para cumprir o prazo, seria necessário limitar o escopo e evitar scope creep.

Conter escopo não é necessariamente sinal de fracasso. Em um portal que reúne identidade, permissões e operações sobre recursos de Internet, uma base menor e coerente pode ser mais segura que um pacote amplo sem aceite representativo. Também pode ser mais correto construir regras comuns do que manter lógicas diferentes em sistemas antigos. A ata, porém, não diz que uma função específica saiu do escopo. Não autoriza imputar o ajuste a AS0, transferências, abuse contact ou AS-SET.

A página da AFRINIC na AfPIF 2026 descreve MyAFRINIC v2 como uma reconstrução completa do portal de autosserviço. Antes de user acceptance testing e live beta, solicitava testadores e entrevistas sobre fluxos cotidianos. É uma evidência de preparação e convite. Não comprova UAT terminada, beta iniciada ou concluída, nem produção geral.

Há ainda a data de 15 de novembro de 2026, citada no staff assessment de AS-SET. O plano dizia que os recursos estavam canalizados para MyAFRINIC v2 e que o trabalho da proposta seria priorizado depois. A ata de junho usava a formulação mais ampla do fim do ano. O registro correto mantém as duas: uma expectativa específica dentro de uma avaliação e uma expectativa geral dentro de uma apresentação de status.

Não se deve transformar 15 de novembro em compromisso universal para quatro políticas. Na data de corte das evidências, o dia ainda não havia chegado. Nem lançamento nem atraso estavam provados. O marco mostra dependência; não entrega aceite por antecipação.

AS0: parcial só é informativo quando tem borda

O registro atual de políticas lista AFPUB-2019-GEN-006-DRAFT03, RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space, como ratificada e Awaiting Implementation. A ata de AFRINIC-37 acrescenta etapas. Havia testes internos com uma evolução do software KRILL. Um beta era esperado para o fim daquele mês e seria anunciado como partly implemented. A implementação integral, tal como escrita, dependia de MyAFRINIC v2.

Esses termos já formam uma sequência de quatro estados: ratificação, teste interno, implementação parcial e implementação completa conforme o texto. Juntá-los em “função RPKI disponível” apagaria a parte mais importante do relato.

O aceite de AS0 deve dizer quais objetos e recursos entram na cobertura, quais casos permanecem fora, como se detecta e corrige uma publicação indevida e qual condição encerra o estado parcial. As fontes conferidas não fornecem essa matriz e não demonstram que o beta previsto tenha ocorrido. Não cabe inventar os campos ausentes.

Cabe exigir que uma futura prova conecte o texto ratificado, a baseline do portal, o estado relevante de KRILL, os casos testados e a operação observada. Teste interno prova lógica sob condições controladas. Não prova necessariamente papéis de usuário, integrações e correções duráveis. Partly implemented precisa nomear o que existe, o que falta e o evento de saída.

Transferências: um caminho que cruza a fronteira da interface

O resumo de políticas ratificadas data de 4 de fevereiro de 2026 a ratificação de Number Resources Transfer Policy AFPUB-2020-GEN-006-DRAFT03. Segundo a ata, a política cobre transferências intra-RIR e inter-RIR; a reciprocidade com os outros quatro RIRs havia sido confirmada em abril. Member Services mapeava procedimentos com as contrapartes. A implementação do sistema técnico seria priorizada após MyAFRINIC v2.

Uma solicitação pode nascer no portal, mas uma transferência inter-RIR não termina nele. Há elegibilidade, documentos, troca de estados, decisões, atualizações de registro e avisos. A existência de um formulário não comprova que cada rota elegível chega a um resultado atribuível.

O inverso também pode ocorrer. Uma equipe pode ter um procedimento operacional antes de a interface ser aberta a todos os membros. Chamar tudo de “não implementado” por causa do portal também perderia informação. O registro precisa aceitar estados compostos: procedimento mapeado, teste técnico pendente; uma categoria habilitada, outra não; caminho interno disponível, UAT do membro ainda em curso.

Cada rota deve ter pré-requisito, contraparte, caso de teste, ponto decisório, resultado no registro, aviso e modo de retomar ou corrigir. Uma futura transferência pública comprovaria aquela instância, não todas as combinações possíveis.

O tema aqui não é reavaliar as limitações materiais da política de transferências. É evitar que o acesso à interface seja confundido com o aceite de uma operação de ponta a ponta.

Abuse contact: aceitar a sequência, não o endereço

O mesmo resumo data de 4 de fevereiro de 2026 Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07. A AFRINIC-37 registra que a implementação técnica nos sistemas internos seria priorizada depois de concluída a implantação de MyAFRINIC v2.

Um atributo abuse-c e uma caixa de e-mail são entradas. A política operacional precisa de estados: qual registro foi testado, quando a validação começou, o que conta como entrega, resposta ou falha, qual aviso é enviado, como o membro corrige, que exceção existe e quando uma consequência pode começar.

A versão do texto é parte do mecanismo. Uma análise anterior da BTW tratou de Draft 2 e de sua cadeia de consequências. Essa história não pode ser usada como atalho para Draft 7. O sistema deve mostrar que o comportamento deriva do texto ratificado. Procedimentos internos podem detalhá-lo, mas não devem substituir a fonte de autoridade sem registro.

Também aqui o parcial tem várias formas: novos cadastros cobertos, legados ainda não; aviso funcionando, correção não homologada; procedimento interno pronto, interface do membro pendente. Nenhum desses estados precisa ser escondido. Eles só precisam ser nomeados com escopo e condição de saída.

AS-SET: a catraca jurídica vem antes da técnica

AFPUB-2026-ASN-001-DRAFT02 aparecia no registro de propostas em Last Call. As fontes não mostram ratificação. O staff assessment diz que pontos de criação em WHOIS e a interface IRR de MyAFRINIC precisariam mudar para impedir novos AS-SETs sem nome hierárquico. Objetos existentes não seriam renomeados.

Avaliar impacto técnico antes da decisão é prudente. A comunidade precisa saber se a regra é executável e quais sistemas toca. Mas viabilidade não concede autoridade. Enquanto o texto for proposta, a coluna correta é “avaliado”, não “implementado”.

Se houver ratificação futura, o primeiro comprovante será o texto final e sua vigência. Depois, cada caminho de criação precisará de teste. Um bloqueio na interface MyAFRINIC não prova o comportamento de outro ponto WHOIS. Um novo objeto conforme não prova a preservação dos existentes. A proposta contém duas bordas distintas, ambas verificáveis.

Trajetória Estado verificado Relação com MyAFRINIC v2 Aceite ainda necessário
ROAs AS0 Ratificada; Awaiting Implementation; teste interno e beta parcial projetado Implementação integral conforme texto dependente do portal Objetos, cobertura, limite parcial/integral, correções, ativação e publicação contínua
Transferências Ratificada em 4 de fevereiro de 2026; procedimentos em mapeamento Sistema técnico priorizado depois do portal Testes por rota e contraparte, decisão, registro, aviso, retomada e correção
Contato de abuso Ratificada em 4 de fevereiro de 2026 Técnica interna depois da conclusão do portal Vínculo a Draft 7, validação, aviso, correção, exceções e limite de consequências
AS-SET hierárquico Proposta em Last Call WHOIS/portal avaliados; prioridade posterior Ratificação, texto vigente, todos os pontos de criação, proteção e correção dos legados

O registro mínimo de dependência e aceite

Não é necessário publicar código-fonte, tickets, credenciais ou documentação de membros. É necessário conservar um registro que acrescente estados, em vez de substituir o anterior por uma frase mais recente.

O primeiro bloco identifica título, código, versão e estado jurídico. Evita que software planejado durante a discussão seja atribuído depois ao draft errado. Mantém AS-SET como proposta até uma decisão de autoridade.

O segundo fixa a baseline. MyAFRINIC v2 é nome de programa, não versão reproduzível. Um identificador de release ou data de baseline deve mostrar qual comportamento passou pelo teste. Se um patch alterar a regra, ele acrescenta evento e não reescreve a aceitação anterior.

O terceiro classifica a dependência: interface, WHOIS, IRR, RPKI, workflow interno, migração de dados ou procedimento externo. Isso impede que um front-end verde atribua conclusão a um back-end ou a uma contraparte que não foram testados.

Em seguida vêm pré-requisito, responsável, caso de teste e critério. Atribuição não é culpa. Registry Products pode atestar uma baseline; Member Services, uma rota; a equipe competente, uma publicação ou validação; o processo de política, a autoridade do texto.

A população de teste também deve aparecer. Teste interno examina regra e integração. UAT examina papéis e tarefas do membro. Beta examina interações mais próximas da operação. Convite não é resultado, e laboratório não é aceite do usuário.

Por fim, cada linha define parcial e integral, registra aviso e ativação, descreve exceção, rollback e correção, e informa a janela de observação. Disponibilidade do portal é métrica de plataforma. Cobertura AS0, rota de transferência, estado de validação e regra aplicada em cada ponto são métricas de política.

Quatro linguagens de exceção

Uma plataforma comum tende a oferecer uma linguagem comum de falha: indisponível, degradada, normal. As políticas precisam de vocabulário próprio. Em AS0, a exceção pode ser um objeto esperado ausente, uma cobertura errada ou uma correção não propagada enquanto o login permanece saudável. O aceite deve medir publicação, não só uptime.

Em transferências, “aguardando” pode significar documento incompleto, análise AFRINIC, estado pendente da contraparte ou atualização técnica ainda não realizada. O rótulo só é auditável se indicar a fronteira institucional e a próxima ação permitida.

Em abuse contact, envio, entrega, resposta e correção são eventos diferentes. Um sinal técnico não deve virar automaticamente decisão de política. Em AS-SET, antes da ratificação a aplicação da regra seria uma questão de autoridade; depois dela, o erro poderia estar em um caminho de criação que não aplica o texto ou em um legado modificado indevidamente.

É por isso que quatro indicadores verdes num painel não bastam. Verde precisa ter uma definição por linha. A AFRINIC pode publicar critérios e números agregados sem expor dados pessoais ou detalhes de segurança.

O que as fontes não autorizam concluir

O conjunto verificado não prova MyAFRINIC v2 em produção, UAT ou beta concluído, ratificação de AS-SET, implementação integral de AS0, transferências ou abuse contact. Também não prova indisponibilidade, prazo perdido, teste fracassado, transferência rejeitada, contato inválido, colisão AS-SET ou efeito de roteamento RPKI.

Não há um membro demonstrado como vítima do acoplamento. Criá-lo seria substituir governança de evidência por acusação.

A AFRINIC já usa estados úteis: Awaiting Implementation, teste interno, partly implemented, mapeamento de procedimentos, prioridade após o portal e Last Call. O próximo passo é ligar cada termo a versão, teste e correção.

Assim, MyAFRINIC v2 pode continuar sendo a catraca comum do programa. O que não pode é carimbar quatro políticas com um único movimento.

Fontes