Resumo
- O Internet-Draft individual de 29 de outubro propõe seis caminhos RDAP para dados do Internet Routing Registry; três tipos SET e campos de política podem ficar de fora.
- A resposta
/helpdo RDAP da RIPE NCC não anunciairr0, o identificador da extensão. Para aposentar o Whois, operadores ainda precisam conferir a cobertura de cada servidor.
A placa de saída ainda tem asterisco
Na RIPE 93, um operador descreveu o suporte a objetos de roteamento dos RIRs como o último recurso que esperava antes de abandonar o Whois. Seis nomes de consulta num rascunho não garantem essa saída.
Em 29 de outubro, o Datatracker publicou draft-aggarwal-regext-rdap-irr-00. Entre os quatro autores estão Mahesh Aggarwal, da RIPE NCC, e Jasdip Singh, da ARIN. A proposta é consultar dados do Internet Routing Registry (IRR) pelo RDAP: JSON estruturado sobre HTTPS, ao lado dos dados de registro que o protocolo já oferece.
O texto enumera seis caminhos: irr0_route, irr0_routeSet, irr0_autnumSet, irr0_rtrSet, irr0_peeringSet e irr0_filterSet. Uma consulta de rota combina prefixo e ASN de origem. Objetos SET podem expor membros em listas. Uma resposta autnum também pode trazer políticas ordenadas de importação e exportação, incluindo formas multiprotocolo e import-via ou export-via.
O asterisco vem logo depois. A implementação pode escolher se oferece peering-set, rtr-set e filter-set; o campo irr0_policies também é opcional. Um cliente pode entender a nova interface e ainda assim não receber o objeto usado por seu filtro. Seis caminhos no papel não são seis portas em funcionamento.
A descrição da ARIN mostra o que uma migração precisa preservar. Seu IRR fica separado das informações públicas do Whois. Detentores de recursos enviam objetos RPSL; outros IRRs os recuperam para decisões de roteamento. A ARIN oferece NRTM, arquivos para download e consultas Whois na porta 43. Ao descrever seu fluxo NRTM, a ARIN chama certos objetos de “authorized” e explica as verificações de registro e contrato associadas. Uma mudança de protocolo precisa manter esses detalhes operacionais, não apenas trocar texto por JSON.
A documentação atual do RDAP da RIPE Database lista quatro tipos: autnum, domain, ip e entity. A resposta /help obtida diretamente anuncia várias extensões, mas não irr0. Isso descreve o serviço da RIPE NCC neste momento, sem falar pelos demais RIRs. Ainda assim, mostra a distância entre a proposta e um endpoint implantado.
O status do documento é explícito: o Datatracker o classifica como Internet-Draft individual, diz que o IETF não o endossou e que ele não tem posição formal no processo de padrões. Seu estado IESG é I-D Exists. A próxima prova necessária é de implementação.
JSON resolve metade do problema
O rascunho faz um trabalho útil: mapeia conceitos RPSL de rota e SET em objetos RDAP, define caminhos estáveis e transporta políticas em campos ordenados. Isso pode reduzir a quantidade de analisadores diferentes que um cliente precisa manter. Mas a conversão deve preservar o significado. Uma expressão de política é uma declaração, não uma observação BGP. Receber um objeto route pelo RDAP não prova que uma rede anuncia ou aceita aquela rota.
Com campos opcionais, cada servidor decide sua própria fronteira. Um RIR escolhe quais famílias SET e quais dados de política publicar. Essa flexibilidade facilita uma implantação gradual, mas impede usar irr0 como selo universal de completude. O rascunho exige que quem suporta a extensão anuncie irr0 em rdapConformance, inclusive na resposta de ajuda. O cliente pode verificar o anúncio; depois precisa testar as classes que seus filtros e sistemas automatizados realmente consomem.
A seção de privacidade do rascunho aponta outra decisão local: essas consultas podem afetar pessoas incluídas nos registros. Um formato JSON comum não define quais dados de contato cada servidor deve expor. A implementação ainda precisa explicar essa fronteira.
A planilha de migração deve responder: a ajuda anuncia irr0? Quais classes retornam dados? Membros, políticas ordenadas e eventos de registro e alteração são preservados? O que acontece quando uma classe não existe? É possível comparar a resposta com o objeto RPSL e o fluxo de espelho já usados?
O rascunho ainda não publica uma matriz de cobertura implantada entre RIRs. Consultas versionadas a cada serviço participante, comparadas campo a campo com a saída RPSL, mudariam a avaliação.
Na RIPE 93, o operador pediu que colegas verificassem os objetos que usam todos os dias. Esse é o teste. “Temos RDAP” responde como os dados trafegam. O Whois só pode sair quando o registro necessário também chega intacto.
Fontes
- RDAP Extension for Internet Routing Registry (IRR) Objects, draft 00
- Texto integral da minuta
- Transcrição do grupo Database da RIPE 93
- Documentação RDAP da RIPE Database
- Resposta de ajuda RDAP da RIPE Database
- Visão geral do IRR da ARIN
- RFC 2622: Routing Policy Specification Language
- RFC 4012: Routing Policy Specification Language next generation
- RFC 9082: formato de consulta RDAP
- RFC 9083: respostas JSON do RDAP
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Exclusivo para o Círculo Estratégico
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance





