Resumo

  • A versão 1 da prop-173 criaria termos separados para consultas comuns, apresentados em WHOIS, RDAP e na web. Ela continua em discussão na lista do Policy SIG e não é uma política aprovada.
  • A política central teria número de versão, data de vigência, histórico e arquivo, mas a resposta precisaria mostrar apenas o endereço da política atual. Falta um recibo curto que fixe versão, vigência e identidade do documento para aquele resultado.

Uma regra própria para a consulta comum

A consulta de um único recurso não é um espelho. Um operador que precisa confirmar um contato, uma equipe de segurança que investiga um incidente e um pesquisador que faz verificações de baixo volume não estão necessariamente montando uma cópia da base. A APNIC já oferece um acordo para acesso Whois em massa, mas esse instrumento não explica com nitidez quando armazenar, combinar ou reapresentar um resultado ordinário cruza a fronteira.

A página oficial da prop-173 informa que a versão 1 foi enviada à lista do Policy SIG em 17 de agosto de 2026. O status exibido é “Published to Mailing List”. No registro examinado não há avaliação de impacto da Secretaria, consenso, adoção nem aviso de implantação. Portanto, a proposta faria essas mudanças; não se deve descrevê-las como regras já vigentes.

O texto da versão 1 abrangeria pessoas e sistemas que acessem dados autoritativos da APNIC por WHOIS, RDAP, busca web ou APIs equivalentes. Dados espelhados ou encaminhados por outro registro continuariam sujeitos à fonte autoritativa. Alto volume, extratos significativos, espelhamento e bancos substitutos permaneceriam no processo separado de acesso em massa.

O desenho dá espaço explícito a finalidades operacionais e de pesquisa técnica: análise de política de roteamento, solução de problemas, identificação do detentor de recursos, DNS reverso, resposta a abuso e pesquisa sobre a Internet. Ao mesmo tempo, proibiria listas de marketing, coleta sistemática, evasão de limites e revenda dos dados como produto não autorizado. Uma pessoa bloqueada por engano teria uma via de revisão.

Esse é um acordo mais legível. Em vez de forçar o usuário a interpretar um contrato de download, a política apareceria na interação que entrega o dado. A questão deste artigo surge quando essa política ganha uma nova versão e a resposta antiga continua circulando.

O documento muda; o endereço permanece

Na seção de avisos, a proposta faria o WHOIS declarar que os dados do diretório estão sujeitos à política e que consultar ou usar o serviço representa concordância. A resposta RDAP teria um aviso identificando a política, um link com relação terms-of-service, uma nota de propriedade intelectual e o endereço da política atual. A interface web apresentaria a mesma condição ao receber a consulta.

O endereço deveria ser HTTPS, estável, mantido e sem redirecionamento. Separadamente, a política central teria número de versão, data de vigência, histórico de revisões e arquivo das versões anteriores. A APNIC daria aviso público razoável de mudanças; alterações materiais que enfraquecessem proteções voltariam à consulta comunitária.

É uma defesa importante. Um documento central evita que textos extensos divirjam entre protocolos. A URL estável reduz quebra de referências. Versões e arquivo tornam a mudança visível. Aviso antecipado reduz surpresa. Um mecanismo de versão na resposta deve aproveitar esse desenho, e não substituí-lo por cláusulas repetidas em cada pacote.

Mas a URL identifica o lugar atual, não a edição aplicada. Os requisitos da resposta não incluem número de versão, data de vigência nem resumo criptográfico do texto. Se um cliente guardar a resposta numa segunda-feira e abrir o link depois de uma atualização na sexta, verá potencialmente as condições de sexta, não aquelas invocadas quando os dados chegaram.

O arquivo pode permitir reconstrução, desde que exista um horário de consulta confiável e as transições de versão sejam exatas. Um log de cliente, cabeçalho preservado ou captura de rede pode fornecer essa informação. Ainda assim, a prova depende de um registro externo. A própria resposta não carrega a chave que une seu conteúdo à edição relevante da política.

O exemplo ao vivo é apenas um canário

A resposta RDAP da APNIC para 1.1.1.1, congelada para esta análise, já contém um aviso de “Terms and Conditions” com link terms-of-service. Ela também mostra origem dos objetos e um caminho para reportar inexatidões. Não mostra uma versão da política, a vigência dessa versão ou um resumo do documento.

Esse resultado não prova a implantação da prop-173. Uma consulta não representa todos os servidores, nem testa WHOIS, web e demais APIs. Ela serve para uma observação mais limitada: o formato atual consegue levar o usuário a uma página de termos sem registrar qual edição daquela página acompanha a resposta.

RFC 9083 define os avisos RDAP como informações sobre o serviço ou sobre a resposta inteira. A descrição é obrigatória e o aviso pode conter links. Há espaço técnico para a referência atual e para um recibo compacto. O padrão não inventa, por conta própria, uma identidade de versão para a política da APNIC. Conformidade de protocolo não substitui rastreabilidade institucional.

Três registros com perguntas diferentes

O acordo Whois de acesso em massa restringe reprodução, armazenamento, transmissão e repasse em bloco fora de finalidades aceitas. Ele demonstra que condições de uso podem continuar relevantes depois da sessão. Não significa que uma consulta comum deva herdar silenciosamente o mesmo contrato.

Também não se deve confundir o recibo proposto com um registro de direitos por campo. Saber se um valor veio de um membro, da APNIC, de outro registro ou de um fato público exige outra proveniência. O recibo dos termos só identifica o texto que o serviço dizia reger uma resposta. Ele não prova que a APNIC detém todos os direitos alegados nem que toda cláusula é válida.

A Declaração de Privacidade da APNIC situa Whois e RDAP no tratamento de informações de contato e registro. Prender uma versão ao resultado não autoriza qualquer uso dessas informações. Apenas impede que uma discussão posterior comece com um documento diferente daquele apresentado na consulta.

O processo ainda está aberto

O Processo de Desenvolvimento de Políticas se baseia em debate aberto e consenso. Uma primeira versão na lista é material para revisão, não um comando final. Acrescentar identidade de versão aos avisos pode ser uma correção proporcional que preserva todos os objetivos centrais do projeto.

O limite factual precisa permanecer visível. As fontes não mostram usuário sancionado sob a edição errada, alteração secreta, consulta quebrada, dano operacional ou conclusão judicial. A APNIC pode manter registros internos capazes de reconstruir cada publicação. O que se observa é apenas que a v001 não exige que essa prova acompanhe a resposta.

Fontes

Foram usados a página de status da prop-173, o texto da versão 1, o acordo Whois em massa, a resposta RDAP congelada, a Declaração de Privacidade, o processo de políticas e RFC 9083. Eles estabelecem requisitos propostos e um formato observado, não uma disputa sob uma política implantada.