Resumo

  • Os relatórios existentes dos RIR, ICANN e IANA contêm evidências substanciais, mas totais de aparência idêntica podem se referir a diferentes pontos de partida, estados de conclusão, funções dos atores e populações elegíveis.
  • A unidade de comparação deve ser um evento de decisão governado com um identificador opaco estável, um namespace de instituição, uma classe de evento, uma versão de política, uma sequência de estados do ciclo de vida e links explícitos para revisão, correção ou reversão.
  • O tempo de decisão deve separar recebimento, completude documental, revisão substantiva, decisão, notificação e implementação autoritativa; a revisão deve ter seus próprios registros de arquivamento, aceitação, medida liminar, resultado e remédio.
  • Os campos de ator devem descrever papéis institucionais no momento da ação — solicitante, verificador, recomendador, tomador de decisão, implementador e revisor — sem publicar identidades desnecessárias de pessoas físicas ou confundir um papel com autoridade.
  • Os campos de eventos públicos e as evidências protegidas devem ser separados. Um registro público pode expor status, classe de motivo, tempo e proveniência, enquanto documentos de identidade, aconselhamento jurídico, credenciais e material de segurança permanecem controlados e auditáveis.
  • Cada evento deve transportar a versão do esquema e a versão do vocabulário sob as quais foi emitido. Mudanças importantes exigem migrações governadas, reformulações paralelas e versões anteriores preservadas, em vez de reescrita silenciosa.
  • A administração do esquema deve pertencer a um órgão normativo independente e multipartidário com registros abertos de alterações, vetores de teste públicos, divulgação de conflitos e participação equilibrada; ele deve definir a semântica dos dados, não decidir a política dos RIRs ou casos individuais.
  • A Number Resource Society pode defender um esquema aberto, reunir titulares e pesquisadores e publicar comparações baseadas em fontes. Não pode atribuir IDs de eventos, manter registros autoritativos, certificar conformidade, julgar decisões ou operar a autoridade do esquema.

A comparação falha no limite da decisão

ORelatório Anual da RIPE NCC 2025, oRelatório Anual da ARIN 2025, oarquivo de relatórios anuais da APNICe orelatório anual do ICANN para o ano fiscal de 2025mostram que as instituições de recursos numéricos já divulgam informações operacionais, financeiras e de governança substanciais. Osrelatórios mensais de desempenho de recursos numéricos da IANAvão além em um domínio restrito, nomeando estágios e metas para solicitações entre a IANA e os RIRs. O problema não é a ausência completa de divulgação.

A falha de comparação aparece quando um leitor pergunta se dois valores publicados descrevem o mesmo ato institucional. Uma transferência pode ser contada quando submetida, quando considerada completa, quando aprovada ou quando o registro autoritativo muda. Uma correção pode ser contada quando um ticket é fechado, mesmo que um diretório público, delegação reversa ou objeto de segurança de roteamento permaneça desatualizado. Uma revisão pode ser contada como arquivada, aceita, decidida ou implementada. Um total anual geralmente não possui estrutura suficiente para recuperar essas distinções.

É por isso que outro portal abrangente de evidências não resolveria o problema central. Um portal pode coletar números incompatíveis e fazê-los parecer mais ordenados sem torná-los mais comparáveis. Uma longa lista de indicadores de governança também pode se tornar uma ficha de avaliação cuja ponderação oculta escolhas substantivas. A camada que falta é menor e mais exigente: uma representação comum do evento a partir do qual os totais posteriores são calculados.

O esquema de eventos não deve tentar armazenar tudo o que uma instituição sabe. Ele deve fazer uma afirmação limitada sobre decisões consequenciais. Ele identifica o ciclo de vida institucional, a fonte de autoridade, as funções dos atores, o tempo, o resultado, a revisão e o histórico de publicação necessários para reconstruir uma comparação. Indicadores de finanças, concentração, associação e serviços técnicos podem ter padrões separados. Eles não devem ser despejados neste modelo de evento apenas porque um único conjunto de dados parece conveniente.

O escopo são decisões, não um depósito de evidências

Um evento de decisão começa quando uma instituição recebe ou inicia um assunto que pode alterar os direitos de uma pessoa ou organização, status registrado, acesso a serviços, registro de recurso ou estado de segurança de roteamento. Também inclui decisões de governança que alteram as regras sob as quais esses assuntos são tratados. O esquema comum pode cobrir solicitações de alocação e atribuição, transferências, correções de registro, ações adversas de conta, alterações de RPKI iniciadas pelo registro, decisões de associação, revisões formais e decisões políticas. Cada classe usa um envelope compartilhado e um perfil específico da classe.

O esquema não absorve arquivos de caso brutos. Não se torna o registro canônico, substitui RDAP ou WHOIS, emite um certificado, registra a propriedade beneficiária como fato, decide a titularidade legal ou preserva todas as mensagens trocadas com a equipe. Essas funções pertencem à instituição e aos sistemas legais responsáveis pela decisão. O esquema público expõe o suficiente para testar o processo e o resultado, enquanto se refere a evidências protegidas por meio de identificadores controlados.

O escopo deve ser aplicável em nível de campo. Um campo pertence apenas quando ajuda a responder a uma de cinco perguntas: que assunto entrou no processo, sob qual regra, qual função institucional atuou, quando o estado mudou e como o resultado foi revisado ou corrigido? Um campo solicitado que não possa ser vinculado a uma dessas perguntas deve ser rejeitado ou colocado em um padrão de domínio separado. Essa disciplina impede que um esquema de decisão se expanda para um dossiê institucional indiscriminado.

Os perfis de classe devem permanecer restritos. Um perfil de transferência precisa das classes de relacionamento de origem e destino, família de recursos, faixa de tamanho, vínculo inter-regional, resultado da verificação de autoridade e estado de implementação. Um perfil de correção precisa da superfície pública afetada, classe de defeito, tempo de confirmação, reparo autoritativo e status de propagação. Um perfil de revisão precisa do evento contestado, classe de legitimidade, arquivamento, aceitação, proteção provisória, resultado e implementação do remédio. Nomes compartilhados devem significar a mesma coisa em todos os perfis.

Um evento precisa de uma identidade durável

Cada evento governado requer um identificador estável que sobreviva à reatribuição de pessoal, migração de sistema de caso, relatórios anuais e correção posterior. Sem ele, uma revisão não pode ser vinculada de forma confiável à decisão que contesta, uma versão corrigida pode contabilizar duas vezes um caso e dois RIRs podem publicar as duas pernas de uma transferência inter-regional como transações não relacionadas.

O identificador deve ser opaco. Não deve codificar um nome de titular, faixa de recursos, país, resultado, classe de risco ou data de submissão. Codificar esses fatos torna o identificador frágil quando uma classificação muda e pode expor informações protegidas. Uma forma prática combina um namespace de instituição registrado com um valor local resistente a colisões. O valor público permanece estável; a instituição responsável preserva o mapeamento protegido para seu identificador de caso interno.

Estabilidade não significa que toda ação relacionada compartilhe um ID. O modelo precisa de relacionamentos explícitos. Um evento de revisão tem seu próprio ID e um linkreviews_event_idpara a decisão contestada. Uma correção tem seu próprio ID e um linkcorrects_event_id. Uma reversão vincula-se tanto à revisão quanto à decisão original, quando aplicável. Uma transação inter-regional pode ter um ID de correlação derivado conjuntamente, enquanto cada RIR mantém seu próprio evento de decisão local. O tipo de relacionamento carrega um significado que a similaridade de string não pode.

IDs nunca devem ser reciclados. Uma solicitação retirada, um pedido rejeitado ou um evento criado por engano ainda ocupa seu identificador. Se a instituição determinar que dois IDs representavam um único assunto, ela publica um relacionamento de mesclagem e retém ambos os históricos. Se um assunto for dividido em partes separadamente decidíveis, ela publica relacionamentos de divisão. A exclusão silenciosa tornaria impossível reproduzir os denominadores posteriores.

O órgão normativo independente deve manter os namespaces de instituições e a sintaxe do identificador, mas não deve emitir IDs operacionais de eventos. Cada RIR atribui seus próprios IDs sob a sintaxe compartilhada e permanece responsável pela exclusividade. Para uma correlação entre RIRs, os registros participantes geram ou concordam com o valor compartilhado por meio de um protocolo documentado. Nem um grupo de defesa nem o secretariado de padrões se torna um registrador de transações.

O estado do evento é uma sequência, não um rótulo de status

Um único status atual oculta o caminho que o produziu. "Concluído" pode significar que a equipe aprovou uma solicitação, que um registro autoritativo mudou, que o titular foi notificado ou que todas as superfícies técnicas dependentes foram reconciliadas. O esquema deve representar uma sequência ordenada de transições de estado, mantendo um estado atual compacto para uso comum.

O ciclo de vida compartilhado começa comreceived. Pode passar paraacknowledged,awaiting_completeness,complete_for_review,under_substantive_review,decision_recorded,implementation_pending,implemented,notifiedeclosed. Os perfis de classe podem declarar estados inaplicáveis, mas não podem omiti-los silenciosamente. Uma solicitação rejeitada ainda possui um estado de decisão e notificação. Uma solicitação retirada registra quem a retirou e em que estágio. Uma transferência aprovada, mas não implementada, permanece visivelmente incompleta.

As transições precisam de classes de motivo. Um caso pode aguardar evidências do solicitante, confirmação da contraparte, outro registro, um tribunal, análise de sanções, recuperação de segurança ou ação interna. A classe de motivo não atribui culpa automaticamente. Ela identifica a dependência para que o tempo decorrido bruto e o tempo controlado pela instituição possam ser calculados. Cada pausa tem um início, fim, função do iniciador e base política; uma pausa aberta não pode desaparecer no final do ano.

A máquina de estado deve rejeitar transições impossíveis, a menos que um registro de exceção as explique. Um evento não pode ser implementado antes de uma decisão. Uma revisão final não pode preceder seu arquivamento. O fechamento antes da notificação requer um motivo específico da classe. A reabertura cria uma transição de fechado para reaberto com uma função de ator e base, não um novo evento disfarçado de caso não relacionado. Regras de validação capturam esses erros antes da publicação.

O estado atual permanece útil, mas é derivado. A sequência autoritativa é o conjunto somente de anexação de transições e correções. Uma versão pode publicar o estado mais recente para consulta conveniente, preservando as transições anteriores necessárias para calcular duração, reabertura e reversão. Essa distinção é essencial quando um painel e uma auditoria devem reproduzir o mesmo resultado.

O tempo precisa de vários relógios e uma regra de precisão

A comparação de decisões é impossível se as instituições iniciam e param o relógio de forma diferente. O envelope comum deve exigirreceived_at,recorded_atelast_revised_at. Os perfis de decisão adicionam entãocomplete_at,substantive_review_started_at,decision_at,notification_at,implementation_ateclosure_atconforme aplicável. Os perfis de revisão adicionamreview_filed_at,review_accepted_at,interim_relief_at,review_decision_ateremedy_implemented_at.

Esses carimbos de data/hora respondem a perguntas diferentes. O recebimento mede quando a instituição obteve o assunto por meio de um canal reconhecido. O registro mede quando o evento entrou no sistema de casos. A completude mede quando o material necessário estava presente sob a política então em vigor. A decisão mede quando o tomador de decisão autorizado fixou o resultado. A implementação mede quando o sistema autoritativo mudou. A notificação mede quando a parte afetada recebeu o resultado. O fechamento é administrativo e nunca deve substituir a implementação.

Cada carimbo de data/hora deve usar UTC com uma precisão explícita. Se um registro antigo suportar apenas uma data, o valor deve ser marcado como precisão de dia, em vez de convertido para meia-noite e tratado como exato. Horários estimados exigem um método de estimativa. Um valor ausente permanece ausente com um código de motivo; não é definido como igual ao marco mais próximo disponível. Essas regras evitam falsa precisão em reformulações históricas.

O esquema também distingue o tempo do evento do tempo de publicação. Uma decisão tomada na segunda-feira e publicada pela primeira vez na sexta-feira tem dois fatos que vale a pena preservar. Uma correção posterior não altera o carimbo de data/hora da decisão original; ela cria um evento de correção e uma nova revisão de publicação. Os analistas podem então medir a latência da decisão, latência da implementação, latência da notificação e latência da divulgação sem confundi-las.

As durações de calendário e de negócios devem ser deriváveis, mas a versão deve privilegiar o tempo de calendário bruto como base universal. Os calendários de negócios diferem por região e ano. Cada instituição pode publicar seu identificador de calendário, feriados e suposições de horário de serviço para que uma transformação governada produza o tempo de negócios local. Publicar apenas dias úteis ocultaria diferenças no tratamento de fins de semana, feriados e emergências.

Os campos de ator devem registrar funções, não biografias

A questão decisiva de responsabilidade raramente é a identidade pública da pessoa natural. É se uma função autorizada agiu, se os deveres foram separados e se a autoridade existia no momento. O esquema deve, portanto, modelar funções de ator independentemente dos nomes.

O vocabulário comum de funções inclui solicitante, titular afetado, oficial de recepção, verificador de evidências, revisor substantivo, recomendador, tomador de decisão, implementador, notificador, revisor independente, autoridade externa e observador de auditoria. Um perfil pode adicionar uma função apenas por meio de uma extensão versionada. Não pode usar um título de texto livre para ocultar que uma pessoa desempenhou várias funções supostamente independentes.

Um registro de função de ator precisa de um ID de evento, código de função, unidade institucional, referência de fonte de autoridade, status de delegação, hora de início e fim e uma chave de ator protegida. A versão pública normalmente expõe o código de função, a instituição e se os requisitos de separação foram atendidos. A camada protegida retém a identidade da pessoa natural ou serviço, evidências de credenciais e a cadeia de delegação para um auditor autorizado ou órgão de revisão.

Função e autoridade não são intercambiáveis. Um campo rotulado comodecision_makerregistra quem executou a função de decisão; um campo separado identifica a política, delegação ou autoridade legal usada. Um membro do conselho não possui autoridade sobre todos os casos apenas por causa do cargo. Um serviço automatizado pode implementar uma ação aprovada, mas não pode ser descrito como o tomador de decisão substantivo, a menos que a política da instituição realmente atribua essa função e o esquema registre a rota de responsabilidade humana.

Os conflitos devem ser estruturados. O evento pode declarar se uma verificação de conflito foi exigida, realizada, divulgada e resolvida, juntamente com a classe de resolução. Não precisa publicar os interesses privados de uma pessoa. Uma auditoria posterior pode testar as evidências protegidas. Essa abordagem apoia a comparação de controles sem converter a versão pública em um banco de dados de pessoal.

A proveniência da política pertence ao evento

Uma decisão não pode ser interpretada sem a regra em vigor quando foi tomada. Vincular apenas a uma página de política atual é inadequado porque as páginas mudam e as URLs podem permanecer constantes. Cada evento deve carregar um identificador de instrumento de política, versão, data de vigência e resumo imutável ou referência de arquivo. O perfil também registra a versão do procedimento e a versão do vocabulário do código de motivo.

A referência de autoridade deve ser específica o suficiente para distinguir política de orientação de implementação. Uma aprovação de transferência pode citar a política de transferência e um procedimento da equipe. Uma ação adversa pode citar um termo de contrato, regra política ou ordem legal externa. Uma decisão de governança pode citar estatutos, um procedimento de consulta e a decisão registrada. O esquema não decide se essas autoridades eram legais; ele preserva no que a instituição se baseou para que a revisão possa testar a alegação.

Os códigos de motivo devem ser estáveis e limitados. "Administrativo" ou "outro" não podem se tornar um recipiente universal. Uma rejeição pode dizer respeito a elegibilidade, evidências, autoridade, incompatibilidade de política, disputa não resolvida, restrição de sanções ou retirada. Um resultado de revisão pode manter, variar, reverter, remeter, rejeitar por legitimidade, rejeitar por atraso ou encerrar por retirada. Texto livre pode permanecer no registro protegido, enquanto o código público suporta comparação agregada.

Quando uma política muda durante um caso pendente, o evento deve identificar a regra de transição. A política antiga continuou, a nova política se aplicou ou a instituição fez uma determinação específica do caso? Esse fato é analiticamente importante porque um acúmulo processado sob regras variáveis pode, de outra forma, aparecer como uma mudança no desempenho ou nos resultados.

A revisão deve estar vinculada à decisão e ao remédio

As estatísticas de apelação são fracas quando não podem ser vinculadas à decisão subjacente. O esquema de eventos deve tornar a revisão um evento vinculado de primeira classe. Ele registra o ID do evento contestado, rota de revisão, classe de legitimidade, tempo de arquivamento, aceitação ou rejeição para revisão, proteção provisória, função de revisão, resultado, motivos, remédio e implementação.

Essa separação evita várias distorções. Uma reclamação não é automaticamente uma revisão aceita. Uma decisão de revisão não é um remédio até que o registro a implemente. Um caso remetido retorna a um estágio de decisão e deve permanecer vinculado. Uma ordem judicial pode ser um evento de autoridade externa que causa um evento de implementação de registro; o esquema não deve representar o registro como o tribunal ou o tribunal como o registro.

O registro público pode publicar classes de motivo e resultado sem expor submissões legais. Pode mostrar que uma decisão de transferência foi revertida porque o teste de autoridade original falhou, ou que uma revisão foi rejeitada por falta de legitimidade, enquanto a camada protegida retém os documentos. Onde até a classe de motivo identificaria uma pessoa em um pequeno coorte, a publicação pode ser atrasada ou agregada, mas a verificação de conformidade confidencial ainda a inclui.

A medida liminar merece um carimbo de data/hora e escopo. Uma revisão pode estar formalmente disponível, mas praticamente inútil se uma mudança irreversível ocorrer primeiro. O esquema registra se o alívio foi solicitado, quem o decidiu, qual ação foi suspensa, quando a proteção começou e quando terminou. Não prescreve que toda revisão receba alívio; torna visível a regra e a ação da instituição.

Os remédios devem usar um vocabulário controlado: corrigir registro, restaurar acesso, repetir decisão, suspender retenção, reemitir credencial, publicar correção, reembolsar taxa, notificar serviço dependente, preservar evidências ou nenhuma ação adicional. Um remédio pode conter vários componentes, cada um com uma data de vencimento e status de implementação. Fechar a revisão antes que esses componentes estejam completos deve permanecer detectável.

A correção deve anexar, não sobrescrever

Um esquema de eventos conterá erros. Um sistema de origem pode exportar o carimbo de data/hora errado, um motivo pode ser codificado incorretamente, uma classificação protegida/pública pode falhar ou uma instituição pode descobrir mais tarde que dois eventos estavam vinculados. A confiança depende da correção sem apagamento histórico.

Cada versão pública deve ser imutável. Um evento corrigido aparece em uma versão posterior com o mesmo ID de evento, uma revisão de evento mais alta, um motivo de correção, a lista de campos alterados, a função responsável, o horário da correção e um link para a revisão anterior. A versão anterior permanece disponível. Os consumidores podem escolher a revisão válida mais recente, enquanto as auditorias podem reproduzir o que era conhecido anteriormente.

As correções na representação do esquema são distintas das correções na decisão institucional subjacente. Se uma decisão ocorreu em uma data, mas a exportação usou a data errada, uma revisão de evento repara os dados. Se a instituição alterar a decisão após a revisão, um evento de reversão vinculado ou um evento de decisão substituto registra o ato institucional. Tratar este último como uma correção de dados apagaria a responsabilidade.

A exclusão deve ser excepcional. Um campo público que contenha acidentalmente dados pessoais protegidos pode precisar de remoção imediata do arquivo ativo, mas o catálogo de versões deve preservar um registro de falecimento que identifique o evento afetado e o motivo sem reproduzir os dados. As evidências protegidas do incidente permanecem disponíveis para investigadores autorizados. Constrangimento comum, reclassificação ou um resultado melhorado não são motivos para exclusão.

Campos públicos e protegidos formam duas camadas coordenadas

O esquema precisa de um perfil público e um perfil de evidências protegidas. O perfil público apoia a comparação: ID de evento opaco, instituição, classe, estados do ciclo de vida, categorias de função, referências de política, carimbos de data/hora, resultado, links de revisão, histórico de correção, revisão de publicação e limitações. O perfil protegido apoia a verificação: mapeamento interno de casos, identidades, referências de evidências, material legal, detalhes de segurança, recursos exatos onde a publicação exporia uma parte e anotações do auditor.

As duas camadas devem compartilhar identificadores e verificações de integridade. Um auditor deve ser capaz de confirmar que todo evento protegido elegível tem uma representação pública ou um motivo de supressão válido. Os agregados públicos devem reconciliar com as contagens protegidas. Uma linha pública pode carregar um compromisso com evidências protegidas sem usar um hash previsível de dados pessoais. O projeto criptográfico deve ser revisado de forma independente, em vez de improvisado por cada instituição.

As regras de privacidade pertencem ao esquema, não a um script de versão não documentado. Cada campo deve ter uma classificação, propósito, público permitido, classe de retenção, regra de agregação e data de revisão. Os perfis de evento devem especificar tamanhos mínimos de célula e riscos de vinculação. Um ID de evento inofensivo em uma tabela pode se tornar identificador quando vinculado a uma ação judicial rara ou a um pequeno coorte regional.

IDs estáveis, portanto, não exigem possibilidade de junção pública ilimitada. A camada protegida retém o ID canônico do evento. As versões públicas podem usar pseudônimos com escopo para perfis particularmente sensíveis, com uma passagem de proteção auditada para completude. Um link de revisão necessário para responsabilidade pode permanecer público onde for seguro; um link entre domínios de sanções, disputas e identidade pode exigir acesso controlado. A regra de publicação deve ser explícita e versionada.

A auditoria independente é essencial porque o público não pode verificar eventos omitidos inspecionando apenas as linhas públicas. Os auditores precisam de acesso a regras de elegibilidade, sistemas de origem, logs de supressão e a passagem de proteção. Sua declaração de garantia deve identificar o período, classes de evento, testes, exclusões e discrepâncias não resolvidas. Não deve afirmar que toda decisão subjacente estava substantivamente correta apenas porque a exportação foi reconciliada.

As versões do esquema devem viajar com cada evento

Um esquema que muda sem disciplina de versão fabricará tendências. Um campo pode ser renomeado, um estado dividido em dois, uma regra de elegibilidade restrita ou um código de motivo aposentado. Se eventos antigos e novos forem combinados sem preservar a mudança, a melhoria aparente pode não passar de uma nova definição.

Cada evento deve transportar pelo menos quatro versões: versão do envelope do esquema, versão do perfil da classe, versão do vocabulário e versão da política de origem. O catálogo de versões carrega a versão do formato de publicação. Esses valores não são redundantes. Um perfil pode adicionar um campo específico de transferência sem alterar o envelope comum; um vocabulário pode esclarecer um código de motivo sem reestruturar o registro; uma política pode mudar enquanto o esquema técnico permanece estável.

Versões principais alteram o significado ou a compatibilidade. Versões menores adicionam capacidade opcional compatível com versões anteriores. Versões de patch corrigem erros de especificação sem alterar a semântica pretendida. O órgão normativo independente deve publicar uma classificação de mudança com cada versão e fornecer exemplos de como os registros antigos se comportam. As instituições não devem escolher um rótulo de versão inferior apenas para evitar deveres de migração.

A depreciação precisa de um cronograma. Um campo primeiro se torna desencorajado com uma regra de substituição e mapeamento. Permanece válido por um período definido. A remoção ocorre apenas em uma versão principal. Os consumidores recebem avisos legíveis por máquina, enquanto os registros históricos continuam identificando a versão que os governou. Um analisador posterior nunca deve adivinhar que um campo antigo significa a mesma coisa que um novo.

Extensões são necessárias porque os procedimentos regionais diferem. Uma extensão usa um namespace registrado, declara seu propósito e declara se afeta elegibilidade, estado ou resultado. O relatório de conformidade principal lista as extensões usadas. Uma extensão regional não pode redefinir um campo principal mantendo seu nome. Se uma diferença for importante o suficiente para alterar o significado principal, ela pertence ao processo de mudança de padrões.

A migração é uma transformação governada

A comparação histórica requer reformular eventos antigos em versões mais novas, mas a migração pode inventar precisão que a fonte nunca conteve. Uma transformação governada deve preservar o evento de origem, código de transformação, versão de mapeamento, tempo de execução, operador e resultado de validação. Ela cria uma representação derivada; não reescreve a evidência original.

Cada campo mapeado precisa de uma classe de proveniência. Direto significa que a fonte continha a mesma proposição. Derivado significa que uma regra determinística o calculou. Inferido significa que as evidências apoiaram uma conclusão limitada, mas não o campo exato. Desconhecido significa que o registro histórico não suportava o valor. Inaplicável significa que a classe de evento não o exigia. Essas classes impedem que um espaço em branco se torne zero e uma data aproximada se torne um carimbo de data/hora exato.

Migrações principais devem publicar uma tabela de concordância. Ela identifica campos preservados, renomeados, divididos, combinados, aposentados e recém-indisponíveis. Um conjunto representativo de eventos históricos torna-se um corpus de teste público com dados sintéticos ou com segurança editados. Implementadores independentes executam a transformação e comparam os resultados antes que a versão seja aceita.

A reformulação paralela é necessária quando uma mudança semântica afeta as tendências. Por pelo menos um período de transição, as instituições devem publicar resultados sob as versões antiga e nova onde os dados de origem permitirem. A diferença quantifica o efeito da mudança de definição. Se a reformulação for impossível, a versão marca a ruptura em vez de desenhar uma linha contínua.

A migração também se aplica quando um RIR muda de sistemas de caso. O ID de evento estável e o histórico do ciclo de vida devem sobreviver. Os identificadores do sistema de origem podem mudar, mas o mapeamento protegido registra a transição. As contagens antes e depois da migração devem reconciliar, incluindo eventos retirados, reabertos e suprimidos. Uma cópia de banco de dados bem-sucedida não é suficiente se os relacionamentos de decisão ou carimbos de data/hora perderem significado.

Eventos inter-regionais precisam de correlação sem custódia central

Uma transferência inter-regional ilustra por que os relacionamentos de eventos são importantes. Dois RIRs podem tomar decisões distintas sob políticas diferentes, mas a transação tem um escopo de recurso compartilhado e não pode ser globalmente completa enquanto seus estados autoritativos discordarem. Um esquema comum deve representar tanto a autonomia local quanto o resultado vinculado.

Cada RIR publica seu próprio ID de evento, proveniência de política, ciclo de vida, funções de ator e resultado. O par também carrega um ID de correlação, um resumo do conjunto de recursos ou faixa de tamanho segura e marcos de hand-off acordados. Uma instituição pode atingir a aprovação local antes da outra. O esquema preserva essa diferença em vez de colapsá-la em uma decisão centralizada.

O protocolo de correlação deve definir quem gera o valor compartilhado, como ambas as partes o confirmam e como um link equivocado é corrigido. Não deve exigir que um terceiro detenha o arquivo de transação subjacente. O órgão normativo independente mantém o protocolo e os vetores de teste. Os RIRs participantes permanecem custodiantes dos registros operacionais e são os únicos órgãos que implementam suas respectivas decisões.

Solicitações de numeração voltadas para a IANA podem usar o mesmo princípio. A disciplina de desempenho publicada da IANA mostra estágios definidos de reconhecimento, resposta e implementação em um limite institucional específico. Um evento RIR vinculado pode se referir à solicitação da IANA sem afirmar que toda decisão do RIR voltada para o titular compartilha a mesma política ou meta de serviço.

A correlação também é útil para revisão e correção entre instituições. Se um RIR alterar sua perna após uma revisão, o parceiro pode publicar um evento de reconciliação vinculado. O registro mostra qual instituição agiu, sob qual autoridade e quando o estado compartilhado se tornou consistente. Não inventa um tribunal global.

O órgão normativo deve governar a semântica, não os resultados

Nenhum RIR isolado deve controlar o vocabulário de comparação para seus pares. Nem um grupo de defesa, auditor, fornecedor ou instituição de pesquisa deve se tornar o regulador oculto ao possuir o esquema. A administração deve estar com um órgão normativo independente e multipartidário cujo mandato se limita à semântica, interoperabilidade, regras de privacidade e métodos de conformidade.

Suas circunscrições governantes devem incluir todas as cinco comunidades de RIR, serviços de numeração da IANA, operadores de rede, titulares de recursos, pesquisadores técnicos independentes, especialistas em privacidade e auditores. A participação precisa de afiliações e conflitos publicados. Nenhuma circunscrição deve ser capaz de enfraquecer um denominador, remover um estado ou redefinir um resultado apenas para melhorar seu próprio desempenho aparente.

O órgão deve publicar propostas, históricos de emissões, registros de reuniões, textos de rascunho, relatórios de implementação e disposições registradas. Mudanças importantes exigem um período de comentários públicos, análise de impacto, revisão de privacidade, plano de migração e pelo menos duas implementações independentes. Correções de segurança de emergência podem usar um processo acelerado, mas expiram a menos que ratificadas pela rota ordinária.

Um secretariado técnico pode manter especificações, registros de namespace, exemplos e ferramentas de validação. Não pode atribuir IDs operacionais de eventos, inspecionar casos protegidos de RIR como rotina, decidir se um solicitante deve receber recursos, anular uma decisão de registro ou certificar uma política como legítima. Auditores independentes realizam garantia específica da instituição sob critérios publicados; o órgão normativo mantém os critérios e reconhece relatórios que atendem ao formato, não à decisão substantiva.

O financiamento deve ser diversificado e divulgado. Um esquema mantido inteiramente pelas instituições que estão sendo comparadas corre o risco de definições defensivas. Um órgão financiado por um grande usuário comercial corre o risco de campos otimizados para o mercado desse usuário. Contribuições fixas, cotas limitadas, orçamentos públicos e regras de conflito podem reduzir a captura. A participação técnica deve permanecer possível para operadores menores e membros afetados sem taxas de viagem ou associação caras.

A conformidade deve ser testável em camadas

A conformidade não deve ser um único distintivo. Uma instituição pode implementar a sintaxe do registro omitindo eventos elegíveis, ou publicar eventos completos classificando erroneamente dados protegidos. O padrão deve definir camadas separadas e exigir que os relatórios declarem quais foram testadas.

Conformidade sintática pergunta se os arquivos analisam, os campos obrigatórios aparecem, os identificadores têm forma válida, os carimbos de data/hora incluem precisão e os valores enumerados usam o vocabulário declarado. Conformidade de ciclo de vida testa transições de estado permitidas e integridade do relacionamento. Conformidade semântica amostra casos de origem para determinar se os campos representam as proposições definidas. Conformidade de cobertura reconcilia eventos de origem elegíveis com registros públicos emitidos ou validamente suprimidos.

Conformidade de privacidade testa classificação, agregação, vinculação e controles de acesso.

O órgão normativo deve publicar esquemas legíveis por máquina, exemplos inválidos, casos extremos e vetores de teste. Os exemplos devem cobrir retirada antes da completude, aprovação aguardando implementação, revisão com medida liminar, correção após publicação, correlação entre RIRs, carimbos de data/hora históricos de precisão diária, pequenos coortes suprimidos e mudança de política durante um caso pendente. Passar apenas exemplos fáceis provaria pouco.

O relatório de conformidade de um auditor deve identificar versões, classes de evento, período, plano amostral, sistemas de origem, reconciliação de cobertura, exceções e datas de remediação. Uma falha em uma camada não deve ser ocultada pelo sucesso em outra. "Válido no esquema" não é abreviação de completo, preciso, privado ou justo.

A linguagem de certificação também precisa de moderação. O provedor de garantia independente pode afirmar que uma versão estava em conformidade com testes especificados por um período. Não certifica que o RIR fez escolhas políticas corretas ou que toda decisão era legal. O órgão normativo deve publicar o relatório e o status de conformidade, mas não deve se tornar um órgão de apelação para casos individuais.

O esquema deve frustrar jogos previsíveis

Uma vez que as medidas de evento se tornem públicas, as instituições responderão. Um relógio de completude pode incentivar a equipe a atrasar a declaração de um arquivo como completo. Uma meta de decisão pode incentivar a rejeição prematura. Uma baixa taxa de reversão pode incentivar barreiras à revisão. Uma contagem de fechamento pode incentivar o fechamento administrativo antes da implementação. O esquema deve expor essas substituições.

O recebimento permanece fixo mesmo que a completude venha depois. Solicitações de material adicional formam transições com carimbo de data/hora e classes de motivo. Rejeição, retirada, abandono e implementação são resultados separados. Casos reabertos permanecem vinculados. O tempo bruto é sempre derivável mesmo quando o tempo controlado pela instituição exclui pausas justificadas. Essas regras dificultam a movimentação do atraso para fora do intervalo medido.

Os coortes de resultado devem seguir os eventos após a decisão. Uma transferência aprovada em um ano, mas implementada no próximo, permanece vinculada entre versões. Uma correção de registro aparece no coorte que recebeu a decisão original, bem como no período de correção. As taxas de revisão usam decisões elegíveis como denominador e divulgam revisões aceitas, rejeitadas e retiradas. O registro de evento suporta esses cálculos sem incorporar um painel preferido no padrão.

Os códigos de motivo devem ser monitorados quanto a desvios. Um aumento súbito em "outro", "atraso do solicitante" ou "fora do escopo" pode refletir uma mudança real ou uma manipulação de classificação. O relatório de conformidade pode amostrar as evidências protegidas e publicar se a codificação permaneceu consistente. Não deve expor partes ou julgar novamente todos os julgamentos.

O órgão do esquema deve avaliar as medidas a cada três anos. Campos que não suportam decisões, não podem ser implementados proporcionalmente ou criam riscos desnecessários à privacidade devem ser revisados ou retirados por meio de um processo versionado. Novos campos exigem um uso definido e um plano de migração. O objetivo não é a coleta máxima; é a comparabilidade durável no ponto em que o poder institucional atua.

Uma versão mínima pode permanecer restrita

O padrão de eventos não precisa de um portal público gigante. Cada instituição pode publicar um pequeno conjunto de arquivos versionados sob URLs estáveis. O primeiro arquivo é uma tabela de envelope de eventos. O segundo contém transições de ciclo de vida. O terceiro contém relacionamentos de eventos. O quarto contém registros públicos de função de ator. O quinto é um catálogo de versões com versões de esquema, resumos, cobertura, contagens de supressão, correções e relatórios de conformidade.

Resumos legíveis por humanos devem ser gerados a partir desses arquivos, não mantidos como números separados. Um painel de transferência pode calcular distribuições de decisão e implementação. Uma página de revisão pode mostrar resultados e conclusão de remédios. Um relatório anual pode citar os mesmos totais derivados. Quando uma correção chega, o catálogo identifica quais versões e resumos mudaram.

Os campos públicos mínimos são ID do evento, namespace da instituição, classe do evento, estado atual, versão da política, horário de recebimento e precisão, horário da decisão, horário de implementação quando aplicável, classe de resultado, funções públicas de ator, link de revisão, revisão de correção, versões do esquema e metadados de publicação. Perfis de classe opcionais adicionam apenas os campos necessários para interpretar esse tipo de decisão.

Tabelas agregadas permanecem úteis para privacidade e comunicação. Devem nomear a consulta exata do evento, versão do esquema, período e regras de inclusão usadas. Uma porcentagem publicada deve ser reproduzível a partir de um arquivo público onde a privacidade permitir, ou a partir de uma consulta protegida verificada por auditor onde não permitir. O agregado é uma visão sobre o registro de evento, não uma fonte concorrente de verdade.

Licenciamento aberto e arquivos duráveis são importantes. Os pesquisadores devem poder recuperar a versão que estava disponível quando um conselho ou comunidade fez uma afirmação. Arquivos revisados não devem sobrescrever os anteriores. Resumos de arquivos, catálogos assinados e espelhos independentes podem suportar integridade sem transferir a autoridade operacional do registro para o espelho.

A Number Resource Society tem apenas um papel de defesa

A Number Resource Society pode dar uma contribuição construtiva argumentando que os titulares merecem registros de decisão comparáveis, publicando pesquisas baseadas em fontes sobre onde as definições divergem, reunindo membros e especialistas técnicos e submetendo propostas de esquema por meio do processo normativo independente. Com autorização explícita de um membro, pode ajudar esse membro a explicar como um registro de decisão ou link de revisão deixou de representar o processo vivenciado.

A NRS não deve manter o registro de namespace, atribuir IDs de eventos de RIR, receber exportações de casos protegidos, operar o serviço de correlação, certificar conformidade, adjudicar disputas de esquema ou decidir se um resultado de RIR estava correto. Essas funções pertencem ao órgão normativo independente, registros responsáveis, auditores nomeados e instituições de revisão reconhecidas, de acordo com seus mandatos distintos.

Sua pesquisa comparativa deve distinguir um campo público ausente de um dever institucional falho. Um registro pode proteger um campo por um motivo de privacidade válido e ainda assim passar em testes de cobertura confidenciais. Outro pode publicar um campo sob uma definição legada diferente. A NRS pode documentar a lacuna, pedir evidências e defender uma mudança; não pode converter sua interpretação preferida em um registro de registro autoritativo.

A NRS também pode modelar boas práticas em seu próprio domínio, versionando suas submissões de políticas, decisões de associação e correções, enquanto as rotula como registros de defesa ou associação. Uma afirmação de associação da NRS não é evidência de que a NRS alocou, registrou, transferiu ou certificou um recurso numérico. Esse limite deve aparecer em toda comparação pública que nomeie a NRS.

O papel positivo é o escrutínio persistente. Grupos de defesa podem notar quando um denominador muda silenciosamente, quando um link de revisão desaparece ou quando um carimbo de data/hora de implementação é substituído por fechamento administrativo. Eles podem tornar essas perguntas legíveis para os membros. Não precisam de autoridade operacional para melhorar a qualidade do raciocínio público.

A adoção deve começar com duas classes de evento

Uma implementação prática deve começar com decisões de transferência e correções de registro. Elas exercem autoridade consequencial, têm resultados técnicos visíveis e expõem a necessidade de recebimento, decisão, implementação, revisão e links de correção. Também revelam correlação inter-regional e problemas de privacidade sem exigir que o esquema cubra todos os processos de governança de uma vez.

Na primeira fase, as instituições participantes mapeiam seus estados internos para um ciclo de vida comum de rascunho e publicam registros de teste sintéticos. O órgão normativo resolve conflitos semânticos, não diferenças de desempenho. Uma instituição pode ter mais estágios locais; deve identificar qual estágio satisfaz cada proposição comum e preservar o detalhe local como uma extensão.

A segunda fase usa um coorte histórico limitado. Cada instituição reformula um período definido com classes de proveniência para cada campo, publica desconhecidos e executa reconciliação de cobertura sob observação independente. O exercício deve relatar falhas de mapeamento e registros de origem inconsistentes, em vez de preenchê-los com suposições.

A terceira fase publica eventos atuais em uma cadência fixa, vincula revisões e correções e executa auditorias de privacidade e conformidade. Pares de transferência entre RIRs testam a correlação. Usuários públicos reproduzem um pequeno conjunto de consultas acordadas, como distribuições de recebimento bruto a implementação e conclusão de remédio de revisão, para confirmar que a semântica comum funciona.

Somente depois que essas classes se estabilizarem, o padrão deve adicionar ações adversas de conta, decisões de associação, ações de registro RPKI ou decisões de governança. Cada adição requer seu próprio perfil, modelo de ameaça, limite público/protegido e corpus de teste. A expansão por lista de verificação recriaria o pacote de evidências sem foco que este design pretende evitar.

O esquema pode comparar processos sem classificar políticas

Eventos comparáveis não implicam política idêntica. Um RIR pode exigir evidências adicionais para uma classe de transferência. Outro pode ter regras de associação diferentes. Restrições legais, idioma, condições de mercado e design de serviço variam. O esquema registra essas diferenças através da proveniência da política, classe e campos de motivo, em vez de declará-las inválidas.

Um pesquisador pode comparar o tempo bruto e específico do estágio para classes de evento semelhantes, examinar com que frequência as decisões progridem para revisão, identificar quais remédios permanecem não implementados e testar se as mudanças de definição explicam uma tendência. Uma comunidade pode examinar sua própria história antes e depois de uma mudança de política. Um auditor pode reconstruir se eventos elegíveis chegaram à versão. Esses são usos defensáveis.

Uma tabela de classificação composta seria mais difícil de justificar. Mais rápido nem sempre é mais justo se a revisão de evidências for diferente. Mais reversões podem refletir revisão acessível, não más primeiras decisões. Mais correções podem refletir detecção mais forte. O esquema fornece fatos e limitações; não escolhe uma ponderação política. Qualquer pontuação posterior deve divulgar sua consulta, coortes, suposições e sensibilidade, em vez de tomar emprestada autoridade do padrão.

O esquema de eventos também não pode provar propriedade legal, controle benéfico, uso operacional ou segurança de rede. Ele registra o que uma instituição reconhecida decidiu e como o processo se moveu. Uma linha de evento válida ainda pode representar uma decisão contestada ou ilegal. Revisão, tribunais, processos políticos e observação técnica permanecem necessários.

Esse limite é uma força. Um esquema restrito pode alcançar semântica precisa porque não promete verdade universal. Torna os atos institucionais rastreáveis e comparáveis, deixando a autoridade substantiva onde ela pertence.

Lacunas de evidências conhecidas devem permanecer visíveis

Os relatórios públicos atualmente não revelam as estruturas completas de eventos, vinculações de funções internas, mapeamentos de evidências protegidas ou carimbos de data/hora históricos de cada RIR. Este artigo, portanto, não afirma que um mapeamento comum pode ser concluído sem perdas, nem que qualquer instituição nomeada atualmente careça de controles internos adequados. Relatórios anuais e documentos de governança pública mostram resultados, não todos os campos do sistema de casos.

Registros históricos podem suportar apenas datas aproximadas, identificadores de caso variáveis ou links de revisão incompletos. Algumas classes de evento podem ser muito raras para divulgação pública sem risco de identificação. As políticas podem ter mudado sem versões arquivadas legíveis por máquina. Essas são razões para publicar proveniência, precisão e status de supressão, não para fabricar registros completos.

Orascunho revisado do Documento de Governança dos RIRs, aMatriz de Governança dos RIRs da NROe oFundo Conjunto de Estabilidade dos RIRsfornecem contexto institucional para responsabilidade e continuidade. Eles não definem o esquema de eventos aqui proposto. ORelatório Trimestral de Transparência de Sanções da RIPE NCC para o 2º trimestre de 2026demonstra que restrições consequenciais podem ser relatadas de forma agregada com atenção à privacidade, mas não estabelece um vocabulário global de eventos.

O custo de implementação também é incerto. Os RIRs diferem em sistemas de origem, obrigações legais e qualidade dos dados históricos. Um piloto deve publicar esforço da equipe, exceções de mapeamento, descobertas de privacidade e custo de auditoria. O órgão normativo deve usar essas evidências para manter o núcleo proporcional, em vez de reduzir a integridade semântica para reivindicar adoção rápida.

Uma decisão deve permanecer rastreável após o painel mudar

A questão duradoura é simples: um leitor posterior pode reconstruir o que a instituição recebeu, qual regra se aplicou, qual função decidiu, quando o efeito autoritativo ocorreu, se a revisão alterou o resultado e qual significado do esquema governou o registro publicado? Hoje, narrativas anuais e painéis geralmente respondem apenas fragmentos.

Um esquema de eventos versionado não substituiria essas publicações. Daria a elas uma base reproduzível. IDs estáveis preservam identidade. Transições de ciclo de vida preservam sequência. Campos de função preservam responsabilidade institucional sem biografia desnecessária. Referências de política preservam alegações de autoridade. Links de revisão e correção preservam remédios. Perfis públicos e protegidos preservam tanto escrutínio quanto confidencialidade. Migrações versionadas preservam significado ao longo do tempo.

A governança do esquema importa tanto quanto sua lista de campos. Um órgão multipartidário independente deve manter definições, migrações e testes, permanecendo fora das decisões operacionais. Os RIRs devem reter seus registros e autoridade. Auditores devem testar cobertura e semântica. Pesquisadores e grupos de defesa devem interrogar as evidências. Os titulares devem ser capazes de reconhecer o caminho de uma decisão que os afetou.

O resultado é intencionalmente menos ambicioso do que um pacote universal de evidências de governança de registro. Não coleta todos os KPIs, classifica todas as instituições ou centraliza registros protegidos. Padroniza a costura estreita onde a comparação repetidamente quebra: o próprio evento institucional.

Até 2030, uma decisão consequencial de RIR não deve se dissolver em um total anual após o caso ser encerrado. Deve permanecer um evento versionado, limitado e revisável cujo significado sobrevive a um novo painel, um novo sistema de casos e uma nova geração de reivindicações institucionais.

Fontes