Resumo

  • Observação de 26 de outubro de 2026: o AS139620 anuncia 2 prefixos IPv4 com 512 endereços e 1 prefixo /48; visibilidade de 269/269 e 257/257; 7 vizinhos observados, 2 à esquerda e 5 à direita do caminho.
  • Na ficha do diretório, o nome diz PUBLIC COMPANY, o campo de natureza jurídica diz private_company, e a nota de 0,95 repousa em duas evidências de 0,82 — sendo que a entrada do rdap.org não abriu nesta verificação. O próprio texto de data_gaps ainda pede que se confirme o país da entidade legal.
  • Para quem precisa decidir com essa ficha: ela confirma que o número AS existe, que o sistema de rotas o vê desde 4 de setembro de 2019 e que ele continuava anunciado na manhã de 26 de outubro. Ela não confirma porte, sócios, diretoria nem vínculo societário. E 512 endereços medem a largura de uma única borda de trânsito, não a rede inteira da empresa.

O que os roteadores viram na manhã de 26 de outubro

Começo pelos números. A consulta de status de roteamento do RIPEstat registra a hora da consulta em 2026-10-26T00:00:00 e a janela de observação em 2026-10-26T08:00:00 (RIPEstat status de roteamento). Dois valores merecem uma pausa: a visibilidade IPv4 foi de 269 pares RIS entre 269, e a IPv6 de 257 entre 257. Placar cheio.

Placar cheio, sozinho, não é novidade. Uma origem com dois prefixos, cujo upstream entrega rotas normalmente, não escapa a observador nenhum. O que carrega informação é o conjunto seguinte: o espaço anunciado é de 2 prefixos IPv4 somando 512 endereços, mais 1 prefixo IPv6 de comprimento /48; os vizinhos observados são 7. Junte os três e o desenho que aparece não é o de uma operadora nacional, e sim o de uma borda de trânsito pendurada para fora.

A lista de prefixos é esta (RIPEstat prefixos anunciados): 103.142.144.0/24, 103.142.145.0/24 e 2001:df1:4780::/48. Cada um traz uma linha do tempo de 2026-10-12T08:00:00 a 2026-10-26T08:00:00. Aqui é preciso ler com cuidado: a nota da própria resposta informa que rotas vistas por menos de 10 pares de feed completo do RIS ficam de fora. Ou seja, essa linha do tempo diz que os três prefixos permaneceram nessa lista ao longo de 14 dias; não prova que algo mudou em 12 de outubro.

De um /23 para dois /24

O mesmo registro de status entrega a primeira e a última observação. A primeira foi o prefixo 103.142.144.0/23, em 2019-09-04T16:00:00. A mais recente foi 103.142.145.0/24, em 2026-10-26T08:00:00.

Ligando os dois pontos aparece um fato de engenharia concreto: em setembro de 2019 o que se via era um agregado de 512 endereços; na manhã de 26 de outubro de 2026 o que se vê são dois /24 de 256 endereços anunciados separadamente. A aritmética fecha. Um /23 é exatamente a união dos dois /24, sem sobra e sem falta de um único endereço.

Por que dividiram, a medição não responde. Desagregar prefixos pode ser engenharia de tráfego por prefixo, pode ser separação por upstream ou por instalação, e pode ser simplesmente configuração antiga que ninguém juntou de novo. No sentido inverso, se um dia os dois /24 voltarem a um /23, isso também é uma mudança que merece registro, e não “nada aconteceu”. A postura correta é tratar a forma do anúncio como forma, nunca como motivo.

Sete vizinhos, dois lados, e a tentação de chamá-los clientes

O dado de adjacência (RIPEstat vizinhos do AS) distribui 7 vizinhos observados em dois grupos.

À esquerda, dois: AS38082, poder 568, 1007 pares IPv4 e 0 pares IPv6; AS4651, poder 1109, 1230 pares IPv4 e 499 pares IPv6. À direita, cinco: AS139595 (poder 248, 318, 0), AS139692 (248, 562, 0), AS139719 (44, 162, 0), AS151482 (248, 319, 0) e AS154481 (309, 275, 205).

“Esquerda” e “direita” são rótulos que o RIPEstat aplica conforme a posição no caminho AS observado. Isso é topologia, não contrato. Os cinco da direita são redes em que o AS139620 apareceu como upstream nos caminhos observados. Chamá-las de clientes, compradoras ou contrapartes contratuais é colocar dentro de uma medição aquilo que ela não contém. O que o dado sustenta é apenas que existiram caminhos naquelas cinco direções e qual é o porte de pares de cada uma.

A identidade das duas da esquerda não se firmou nos registros públicos que consegui ler nesta verificação. Por isso o texto traz só os números, sem nome de empresa. Não é pudor estilístico: é disciplina de evidência. Confirmar que um número AS existe não confirma quem o opera.

As linhas que o registro desenha

O texto do WHOIS do APNIC (APNIC WHOIS) desenha assim: aut-num AS139620, as-name MTNPCL-AS-AP, descr MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY LIMITED, country MM. A mesma consulta (resposta de consulta APNIC) devolve o identificador de organização ORG-MTNP1-AP.

A visão geral de AS do RIPEstat (RIPEstat visão geral do AS) traz a mesma cadeia de detentor, coloca o número no bloco 139578-140601, cuja descrição é Assigned by APNIC, sob o registro de números de sistema autônomo de 32 bits da IANA, e informa announced true para a janela de 2026-10-26T08:00:00.

O que merece atenção é o caminho que não passa. O objeto RDAP do próprio APNIC (APNIC RDAP autnum) não retornou registro legível nesta verificação. Isso significa que data de alocação, estado do objeto e remarks — o que normalmente se lê em RDAP — não estão disponíveis aqui em nenhum campo. Quem perguntar em que dia o número foi designado recebe, deste texto, a informação de que a resposta não existe; não recebe um ano provável.

Dois documentos, uma nota

Agora a ficha do BTW em si. Ela exibe confidence_score de 0,95. Sua evidence_basis tem apenas duas entradas, cada uma com confiança de 0,82: o documento autnum do rdap.org, rotulado Public registry record, e a visão geral de AS do RIPEstat, rotulada public routing data.

O problema não é citar duas fontes. Citar duas fontes é honesto. O problema é como 0,82 e 0,82 viram 0,95. A ficha não declara o método de agregação. E, para o leitor, o ponto mais concreto é outro: o documento apontado no rdap.org (rdap.org autnum) não resolveu nesta verificação; o resultado da recuperação foi inaccessible, com trecho vazio.

Dos dois documentos citados, um foi lido e o outro não, e ainda assim a nota final subiu de 0,82 para 0,95. Isso não é acusação de fraude; é um problema de reprodutibilidade. O número 0,95 é lido como “dois documentos independentes foram conferidos”, mas o que de fato ocorreu foi “duas entradas de 0,82, uma delas inacessível nesta verificação”. A apresentação honesta seria declarar a regra de agregação, ou manter a nota no piso quando a evidência não abre.

O choque entre o nome e o campo

As cadeias da ficha são estas: legal_name igual a MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L; alias TELECOMMUNICATION NETWORK PUBLIC COMPANY L; legal_type igual a private_company; hq_country e registration_jurisdiction ambos Myanmar (Burma), com hq_country_code MM.

O nome traz PUBLIC COMPANY; o campo traz private_company. Isso é uma divergência entre duas cadeias de texto. Paro por aqui. Não obtive documento constitutivo, extrato de registro comercial nem comprovação de forma jurídica, então não é possível dizer qual das cadeias destoa dos fatos — nem sequer excluir que ambas se sustentem sob alguma definição jurídica. Escrever que a empresa “se passa por companhia aberta” é exatamente o que este texto recusa fazer.

Há uma segunda costura na mesma ficha. Ela preenche a jurisdição como Myanmar (Burma) e, ao mesmo tempo, no data_gaps, pede que se verifique “o país da entidade legal” — e segue listando serviços atuais, ativos visíveis, vínculos de matriz ou subsidiária e contatos de liderança responsáveis. Preencheu o valor e admitiu, no mesmo cartão, que não o verificou. Não é indício de crime; é a ordem de construção da ficha sobrevivendo dentro do produto final.

A terceira costura é mais fina. O nome legal na ficha termina com um L solto, e o descr do APNIC grafa LIMITED. São duas grafias do mesmo detentor, e disso não duvido. Qual delas corresponde ao documento constitutivo, porém, não sei. Sufixos societários costumam aparecer truncados em nomes internacionais, e costumam aparecer por extenso; nenhum dos dois é problema por si. Vira problema apenas quando o nome precisa entrar no campo de parte contratante de um contrato.

Um AS classificado como virtual

A ficha lista exatamente um recurso: AS139620, com resource_type asn, resource_class virtual, status observed, service ip_transit e país Myanmar (Burma).

Há uma palavra aqui que não vou contornar: virtual. Um número AS é coisa concreta em URL, em consulta e em tabela de rotas, mas esta ficha classifica o recurso como virtual. O que virtual significa neste sistema de diretório, esta verificação não conseguiu obter. Pode ser lido como “este recurso não é um bloco de endereços próprio” e pode ser lido como outra coisa qualquer de classificação. Sem definição, o texto reporta o valor do campo e não interpreta por conta própria.

A camada de serviço é uma só: roles como provider, região MM, serviços ip_transit e managed_network. Dos dois, apenas o ip_transit encontra correspondência na evidência de roteamento que pude ler: os prefixos são anunciados, os vizinhos propagam, isso é trânsito. O managed_network existe como campo da ficha, mas não tem, no material público lido aqui, correspondência verificável. Como registro, ele se sustenta; como capacidade de serviço citável, ainda não.

O vazio fala mais alto

Nesta ficha, o que está vazio ocupa mais espaço do que o que está preenchido: relationships é array vazio, leadership_contacts é array vazio, related_events é array vazio, contextual_references é array vazio; first_seen_at é null, external_id é null, source_system é null, website é null, primaryDomain é null. O status é queued_for_profile_article e o last_updated_at é 2026-06-17T00:04:15.536Z.

Esses vazios não são escândalo; são ordem de construção. Primeiro o número AS é observado, depois vêm pessoas, vínculos e site. A página do diretório está aqui: entrada do diretório BTW Exclusivo para o Círculo Estratégico. Mas, para quem vai decidir com base nela, o vazio define quais perguntas ainda são possíveis. Sem leadership_contacts, não há como perguntar quem atende o telefone numa falha. Sem relationships, não há como perguntar de quem ela é família. Com first_seen_at nulo, não se pode sequer dizer quando a entidade entrou no diretório; o que se pode dizer é que o número já era visto pelo sistema de rotas em 4 de setembro de 2019.

O que quem decide realmente precisa

Concretizo o leitor. Três tipos param diante de uma ficha assim: a operadora que quer se conectar a esse trânsito; a área de compras que precisa preencher uma lista de fornecedores; o analista que escreve um relatório de país ou de região.

As quatro coisas de que eles precisam são prosaicas: a empresa ainda opera; aqueles 512 endereços são dela; quem são os upstreams; quem responde quando algo quebra.

O que esta verificação entrega: o número AS existe; é visto pelo sistema de rotas desde 2019-09-04T16:00:00; seguia anunciado na janela de 2026-10-26T08:00:00; a visibilidade estava praticamente cheia; o espaço anunciado é de 512 endereços IPv4 mais um /48; há 7 vizinhos observados, 2 à esquerda e 5 à direita do caminho.

O que ela não entrega: documento constitutivo, estrutura societária, nomes da diretoria, lista de clientes, porte total da rede. O último item precisa ser dito sem rodeio: 512 endereços são a largura desta borda de trânsito. Uma operadora pode manter o backbone inteiro em outro lugar e pendurar aqui só este trecho pequeno; o contrário também não pode ser descartado. Com esta ficha apenas, nenhuma das duas hipóteses é eliminada.

O uso correto, portanto, é tratar a ficha como pista, não como prova. A pista indica onde perguntar em seguida: peça a evidência de designação ao APNIC, peça um documento de registro conferível, peça uma lista de contatos com SLA. Prova é papel assinado por alguém, não nota atribuída por alguém.

O que derrubaria este julgamento

Um texto sobre limites de evidência deve oferecer suas próprias condições de refutação.

Primeiro, se o objeto RDAP do APNIC voltar a ser legível e trouxer data de alocação e estado do objeto, a afirmação de que não há data de alocação cai imediatamente, e a discussão sobre a cronologia precisa ser reescrita.

Segundo, se o diretório mudar legal_type para public_company, ou se alguém apresentar um documento constitutivo, a tensão entre o nome e o campo fica explicada — em qualquer das duas direções.

Terceiro, se surgir um novo prefixo, ou se os dois /24 voltarem a ser um /23, o número 512 deixa de ser “atual” e volta a ser “um retrato daquele momento”.

Quarto, se o documento do rdap.org voltar a abrir, o problema aritmético entre 0,95 e 0,82 continua de pé, mas a constatação de que ele não abria deixa de valer.

Quinto, se o conjunto de vizinhos mudar, a descrição dos lados esquerdo e direito precisa ser remedida. Medição tem data; descrição também tem prazo de validade.