Resumo

  • O RFC 10040 é um RFC Experimental do fluxo IETF, com consenso da comunidade, revisão pública e aprovação do IESG. Ele não faz parte do Internet Standards Track e esclarece que Experimental indica a maturidade da tecnologia, não um experimento operacional já definido.
  • O registro vigente da IANA mantém o tipo LCAF 5 como Geo-Coordinates (DEPRECATED) e atribui separadamente o tipo 17 a Geo-Location. Obsolescência não é exclusão, e alocação não comprova que produtos já enviem, interpretem ou usem o novo formato.
  • Um comprovante de migração precisa separar status do documento, códigos antigo e novo, capacidade de cada implementação e par, pacotes observados, fallback, tratamento de tipos desconhecidos e as políticas de origem, precisão e acesso dos dados de localização.

Publicação, registro e execução são fatos diferentes

O RFC Editor anunciou o RFC 10040 em 15 de setembro de 2026. O documento atualiza a seção 4.3 do RFC 8060, torna obsoleta a codificação Geo-Coordinates identificada pelo tipo LCAF 5 e define Geo-Location sob o tipo 17.

Essa linha do tempo reúne provas diferentes. O grupo de trabalho LISP concluiu um texto. O IESG aprovou sua publicação em 15 de março. O RFC Editor publicou o RFC final seis meses depois. A IANA coordenou as entradas do registro. Ainda falta demonstrar quais versões implementam a codificação e quais pares a trocam de ponta a ponta.

O próprio status do RFC fixa o limite: houve consenso da comunidade IETF, revisão pública e aprovação pelo IESG, mas o texto não é uma especificação do Internet Standards Track. Consenso responde qual documento terminou o processo. Não responde se um operador ativou o tipo 17 nem se pode retirar o tipo 5.

Experimental não significa que exista um experimento

A introdução declara que o trabalho não faz parte de um “experimento”, porque nem todo RFC Experimental precisa fazer parte de um. A categoria descreve o nível de maturidade da tecnologia.

Isso impede duas leituras erradas. Experimental não equivale a inseguro por definição; tampouco equivale a um teste de campo em andamento. O RFC 7841 fala em exame, implementação experimental e avaliação, mas não fornece ao RFC 10040 uma hipótese, um grupo de teste, telemetria, duração ou limiar de sucesso.

O histórico público registra discussões sobre implementações anteriores, necessidade de implantação, privacidade e precisão. O RFC final é o resultado aprovado. O histórico mostra onde ainda é preciso obter evidência operacional; aprovação não converte perguntas em medições.

Obsoleto não quer dizer apagado

O registro de parâmetros LISP da IANA ainda exibe o tipo 5 como Geo-Coordinates (DEPRECATED), com referências aos RFCs 8060 e 10040. O tipo 17 aparece em uma entrada própria, Geo-Location.

Esse desenho preserva a interpretação do passado e coordena a preferência futura. O RFC 10040 não afirma que o tipo 5 sumiu, que todo receptor deve rejeitá-lo nem que todo emissor migrou. Manter o identificador evita que código e pacotes históricos se tornem ambíguos.

Por isso a obsolescência inicia trabalho. Um emissor que produz apenas tipo 17 precisa de uma base para acreditar na capacidade do receptor. Uma frota pode misturar versões. Um controlador pode gerar o novo corpo enquanto uma ferramenta de observação ainda espera tipo 5. Sem uma negociação universal de capacidade, a prova deve vir de inventário, configuração bilateral, troca de teste ou rollout controlado. Ausência de erro não é comprovação de suporte.

A compatibilidade tem uma assimetria decisiva

A seção 8 trata EID e RLOC de modo diferente. Registros EID Geo-Location só funcionam entre nós LISP que os suportem no registro e na consulta. Registros RLOC Geo-Location podem ser devolvidos a um nó que não os reconheça; nesse caso, são ignorados.

Ignorar corretamente um tipo desconhecido pode manter o protocolo estável e, ao mesmo tempo, impedir a função baseada em localização. O emissor pode formar um tipo 17 válido, o sistema de mapeamento pode transportá-lo e o receptor pode descartá-lo conforme a regra. O caminho parece saudável, mas a informação não é usada.

A evidência de migração deve ser direcional: qual componente e versão emitiram o tipo, qual par o recebeu, como foi classificado, se foi usado ou ignorado e qual fallback preservou a função. A frase “suporta RFC 10040” não distingue essas etapas.

Campos mais detalhados não tornam a localização verdadeira

O tipo 17 adiciona incerteza explícita, milissegundos de latitude e longitude, unidades de altitude e um raio que diferencia Geo-Point de Geo-Prefix. Isso melhora a representação. Não autentica a origem, atualidade ou exatidão dos dados.

Uma coordenada detalhada ainda pode vir de inventário antigo, erro manual ou estimativa ampla. O campo de incerteza carrega uma alegação; não realiza uma medição independente. A presença da coordenada também não prova consentimento, autorização de consulta ou retenção legítima.

O RFC 10040 discute políticas locais de acesso, aplicação por um Mapping Service Provider, respostas assinadas ou criptografadas, Geo-Prefix para reduzir precisão e TTLs curtos para limitar exposição. Ele descreve como uso típico estruturas, locais e marcos públicos, e não pessoas, veículos ou equipamentos. Essas medidas só existem de fato quando são configuradas e observadas.

O comprovante de maturidade e migração

A camada documental deve registrar fluxo IETF, categoria Experimental, datas de aprovação e publicação, seção 4.3 do RFC 8060, tipo 5 obsoleto e tipo 17 atribuído. Qualquer errata ou futura mudança de status entra como novo fato datado.

A camada de compatibilidade deve indicar implementação e versão, papéis suportados, método para verificar a capacidade do par, tipo efetivamente emitido e interpretado, resultado para tipo desconhecido, janela de leitura dupla ou fallback, escopo do teste, falhas, responsável pela correção e critério de retirada. “Aceita os dois” precisa dizer se é só parsing, uso produtivo ou fallback ativo.

A camada de uso deve registrar origem da coordenada, precisão declarada e medida, Geo-Point ou Geo-Prefix, política de acesso, mecanismo de autorização, retenção ou TTL, consumidores posteriores e caminho de correção. Não observado, não testado, não suportado, ignorado e falha de parsing são estados diferentes.

O RFC oferece um artefato comum de coordenação. A IANA coordena o número. A migração vira fato somente quando software executa a decisão, pares interoperam e operadores aceitam os efeitos com limites explícitos.

Fontes e limites

As fontes principais são o RFC 10040, o anúncio do RFC Editor, o histórico no Datatracker, o registro da IANA, o RFC 8060, o RFC 7841 e o RFC 6973. A busca de erratas para o RFC 10040 não tinha resultados em 21 de setembro de 2026.

Essas fontes comprovam status, alocação e semântica. Elas não fornecem uma matriz completa de suporte, censo de implantação, rastreamento de pacotes, cronograma de migração, auditoria de exatidão ou registro de consentimento. A falta desses itens limita a conclusão; não prova que nenhuma implementação exista.