Resumen

  • RFC 10040 es un RFC Experimental del flujo IETF con consenso de la comunidad, revisión pública y aprobación del IESG, pero no forma parte del Internet Standards Track. El propio texto aclara que Experimental describe la madurez de la tecnología, no un experimento operativo definido.
  • El registro vivo de IANA conserva el tipo LCAF 5 como Geo-Coordinates (DEPRECATED) y asigna por separado el tipo 17 a Geo-Location. Obsoleto no significa borrado, y una asignación no prueba que un producto emita, analice o use el formato nuevo.
  • Una constancia de migración defendible debe separar el estado del documento, los códigos viejo y nuevo, el soporte de cada versión, la capacidad del par, los paquetes observados, el repliegue, el tratamiento de tipos desconocidos y las reglas de procedencia, precisión y acceso de la ubicación.

Un RFC publicado no fusiona estados distintos

El RFC Editor anunció RFC 10040 el 15 de septiembre de 2026. El documento actualiza la sección 4.3 de RFC 8060, deja obsoleta la codificación Geo-Coordinates del tipo LCAF 5 y define Geo-Location con el tipo 17.

En esa secuencia hay varias evidencias independientes. El grupo LISP llegó a un resultado de documento. El IESG aprobó su publicación el 15 de marzo. El RFC Editor publicó el texto final seis meses después. IANA coordinó las entradas del registro. Todavía hace falta saber qué versiones implementan el formato y qué pares lo intercambian de extremo a extremo.

El bloque de estado de RFC 10040 dice que hubo consenso de la comunidad IETF, revisión pública y aprobación del IESG. También dice que no es una especificación del Internet Standards Track y que no todo documento aprobado por el IESG es candidato a convertirse en estándar. El consenso certifica el resultado del proceso editorial; no certifica una flota desplegada.

Experimental no describe un experimento en marcha

La introducción corta de raíz una lectura tentadora: el trabajo no forma parte de un «experimento», porque no todo RFC Experimental necesariamente lo hace. La categoría se refiere al nivel de madurez de la tecnología.

Así, Experimental no significa que la tecnología sea insegura por definición, ni que exista ya una prueba de campo con hipótesis y métricas. RFC 7841 habla de examen, implementación experimental y evaluación. No fija para RFC 10040 una cohorte, telemetría, duración, umbral de éxito ni criterio de salida.

El historial público conserva preguntas sobre implementaciones anteriores, necesidad de despliegue, privacidad y precisión de la ubicación. Esas preguntas no invalidan el RFC final, pero tampoco desaparecen por la aprobación. Son incertidumbres que deben convertirse en observaciones si alguien pretende presentar una migración como realizada.

Obsoleto no significa eliminado

El registro de parámetros LISP de IANA sigue mostrando el tipo 5 como Geo-Coordinates (DEPRECATED), con referencias a RFC 8060 y RFC 10040. El tipo 17 aparece en otra fila como Geo-Location.

La conservación del número viejo importa. El registro no está anunciando que todos los receptores deban rechazarlo ni que todos los emisores se hayan actualizado. Mantiene una interpretación estable para paquetes, código y documentación históricos. Reutilizar el 5 como si nunca hubiera existido destruiría esa continuidad.

La obsolescencia abre trabajo operativo. Un emisor que produce solo el tipo 17 debe justificar por qué el receptor puede usarlo. Una flota puede mezclar versiones. Un controlador puede escribir el nuevo cuerpo mientras una herramienta de captura o un validador posterior todavía espera el tipo 5. Como RFC 10040 no crea una negociación universal de capacidades, la prueba puede venir de un inventario, una configuración bilateral, un intercambio de prueba o un despliegue acotado; no puede venir del silencio.

La cláusula de compatibilidad es asimétrica

La sección 8 distingue registros EID y RLOC. Un registro EID Geo-Location requiere nodos que admitan su registro y búsqueda. Un registro RLOC Geo-Location puede llegar a un nodo que no lo entienda; ese nodo lo ignora.

Ignorar un tipo desconocido puede ser comportamiento correcto del protocolo y, a la vez, fracaso de la función que dependía de la ubicación. El emisor puede formar bien el tipo 17, el sistema de mapeo puede transportarlo y el receptor puede descartarlo según las reglas. Nada se rompe de forma visible, pero la información no produce efecto.

Por eso la evidencia debe ser direccional: quién emitió qué tipo, qué par lo recibió, cómo lo clasificó, si lo usó o lo ignoró y qué repliegue sostuvo el servicio. «Compatible con RFC 10040» no tiene suficiente resolución para explicar una flota heterogénea.

Más resolución de campo no garantiza más verdad

El tipo 17 añade incertidumbre explícita, componentes de milisegundos para latitud y longitud, unidades de altitud y un radio que distingue Geo-Point de Geo-Prefix. Son mejoras de representación. No autentican el origen ni la actualidad de las coordenadas.

Una cifra con gran detalle puede proceder de un inventario antiguo, un error manual o una medición mucho menos exacta. El campo de incertidumbre transporta una declaración sobre precisión; no es una auditoría externa. Tampoco la mera aparición de coordenadas demuestra consentimiento, permiso de acceso o una retención lícita.

RFC 10040 analiza políticas locales, aplicación de reglas mediante un Mapping Service Provider, respuestas firmadas o cifradas, Geo-Prefix como reducción de precisión y TTL breves para reducir exposición. Sus casos típicos son estructuras y lugares públicos, no personas, vehículos o equipos. La eficacia de esas medidas depende de configuración y evidencia real.

Una constancia de madurez y migración

La primera capa de la constancia es documental: flujo IETF, categoría Experimental, fechas de aprobación y publicación, sección 4.3 de RFC 8060, tipo 5 obsoleto y tipo 17 asignado. Un erratum o cambio futuro de estado se agrega como hecho fechado, no reescribe el original.

La segunda capa es técnica: implementación y versión, roles admitidos, método para conocer la capacidad del par, formato realmente emitido y analizado, resultado ante un tipo desconocido, ventana de doble lectura o repliegue, alcance de la prueba, fallos, responsable de corrección y criterio de retirada. Aceptar ambos tipos puede significar análisis pasivo, uso en producción o fallback activo; la constancia debe decir cuál.

La tercera capa es el uso de la ubicación: procedencia de las coordenadas, precisión declarada y medida, Geo-Point o Geo-Prefix, política de acceso, mecanismo de autorización, TTL o retención, consumidores posteriores y vía de corrección. «No observado», «no probado», «no admitido», «ignorado» y «error de análisis» deben seguir siendo estados diferentes.

La publicación coordina un texto. IANA coordina un identificador. La migración solo existe como hecho cuando las implementaciones lo ejecutan, los pares interoperan y los operadores aceptan sus efectos con un límite de observación explícito.

Fuentes y límites

La base documental es RFC 10040, el anuncio del RFC Editor, el historial de Datatracker, el registro de IANA, RFC 8060, RFC 7841 y RFC 6973. La consulta de errata no mostraba coincidencias para RFC 10040 al 21 de septiembre de 2026.

Estas fuentes prueban estados documentales, registrales y semántica de protocolo. No incluyen una matriz completa de implementaciones, un censo de despliegue, trazas de paquetes, un calendario de retirada, una auditoría de exactitud ni un registro de consentimiento. Ese límite no autoriza a concluir que no exista ninguna implementación.