Resumen
- El RFC Editor registró la aprobación del autor el 8 de septiembre de 2026 y marcó el futuro RFC 10040 como listo para preparar su publicación. El 9 de septiembre seguía en Final Review, por lo que todavía no es un RFC publicado.
- El formato Geo-Location de LISP puede llevar puntos, Geo-Prefixes menos precisos y un valor de incertidumbre. La política de acceso, el cifrado y las firmas LISP-SEC protegen partes distintas de la distribución.
- Una firma válida atribuye la Map-Reply a quien la firma, pero no demuestra cómo se obtuvo la coordenada ni cuándo se observó. Si la ubicación activará decisiones reales, hace falta un recibo separado de procedencia del posicionamiento.
El último control editorial no certifica el terreno
La novedad tiene fecha y alcance. La Final Review de draft-ietf-lisp-geo empezó el 31 de agosto. La cola del RFC Editor anotó el 4 de septiembre la aprobación del Area Director y la actualización del registro de IANA. El 8 de septiembre llegó la aprobación de Dino Farinacci y el expediente pasó a indicar “Ready to prepare document for publication”. Sin embargo, el estado del 9 de septiembre aún decía “In Final Review”. Se trata del futuro RFC 10040, de carácter Experimental, no de un RFC ya publicado ni de un Proposed Standard.
Ese tramo sirve para cerrar el texto editorial. Si una corrección rebasa lo editorial y altera la técnica, necesita la aprobación del responsable del stream. Las preguntas pendientes sobre terminología, WGS 84, la sección citada por IANA y la descripción de la firma muestran una pieza casi terminada dentro del proceso editorial de la IETF.
La cercanía de la publicación puede producir una falsa equivalencia. Cuando un campo tiene número, estructura exacta y protección criptográfica, parece que cada afirmación incluida comparte la misma garantía. No es así. La Map-Reply puede proceder realmente de su firmante y llegar intacta, mientras la latitud sigue siendo una afirmación cuya historia física no está en el mensaje.
El tipo 17 transporta un sitio, no produce la medición
El documento define el tipo 17 de LISP Canonical Address Format y sustituye el diseño Geo-Coordinates del RFC 8060. Un registro puede expresar un Geo-Point o un Geo-Prefix. El primero conserva un punto; el segundo abre deliberadamente el resultado a un área. Location Uncertainty, un campo en centímetros, representa incertidumbre de radio y altura.
La semántica es más rica, pero no identifica el origen del dato. La coordenada puede proceder de un equipo topográfico, un receptor GNSS, un inventario configurado, un proveedor externo o una carga manual. Tampoco todos los radios significan lo mismo: uno puede estar calculado con observaciones, otro ser un margen conservador y otro una estimación sin método registrado.
La diferencia no convierte el formato en defectuoso. Define dónde termina. El sistema de posicionamiento produce la observación; el mapper la enlaza con un EID o RLOC; el Map-Replier firma la respuesta resultante. Reducir los tres actos a “ubicación firmada” borra qué actor tomó cada decisión y hace que un objeto parezca probarse a sí mismo.
El RFC 6280 propone precisamente separar posicionamiento, distribución y uso. Que un receptor obtenga fielmente lo enviado por un creador no demuestra por sí solo que la afirmación física del creador sea cierta. El matiz adquiere consecuencias cuando una coordenada entra en una infraestructura de mapeo y luego alimenta automatización, cumplimiento o asignación de recursos.
La firma autentica al emisor, no al agrimensor
El futuro RFC 10040 deja normalmente la autorización de una consulta en la política local del xTR. Si un Mapping Service Provider responde como proxy, debe aplicar la política del xTR. Un solicitante autorizado puede recibir una Map-Reply firmada conforme a LISP-SEC y, cuando corresponda, cifrada. Esas medidas autentican al Map-Replier, preservan la integridad y limitan la divulgación.
No revelan si la coordenada se tomó hace segundos o meses, si el sensor estaba calibrado, si el activo se movió, si hubo un error al copiarla o si la incertidumbre se derivó empíricamente. La autorización decide quién puede recibir la afirmación. No determina si la afirmación aún corresponde al mundo físico.
El propio documento reconoce varias relaciones de confianza. También advierte que las coordenadas pueden facilitar el seguimiento de hosts cuando los EID se asignan a hosts. Geo-Prefix permite perder precisión; un TTL corto reduce la vida del registro; la autenticación y la política restringen a los solicitantes. La aplicabilidad típica habla de estructuras públicas y puntos de referencia, no de personas, vehículos o equipos. Son defensas sensatas, pero minimizar exposición, demostrar exactitud y autorizar un uso posterior siguen siendo tareas diferentes, como recuerda el RFC 6973.
Un recibo para el momento en que una coordenada se vuelve evidencia
No hace falta inflar el significado de la firma. Puede añadirse un recibo portátil junto al objeto. Si una operadora, aseguradora, autoridad de emergencias, regulador o controlador automático actuará porque un registro sitúa un activo en cierto lugar, debería poder revisar la cadena de evidencia que generó esa ubicación.
El recibo debería identificar sujeto o activo, método de posicionamiento, sensor o fuente anterior, hora de observación, sistema de referencia de coordenadas, método de cálculo de la incertidumbre, mapper que armó el registro, firmante de la respuesta, versión o época de la política de acceso, vencimiento y resultado de una verificación posterior. No es obligatorio mostrar trazas sensibles a todo solicitante. Una clase de garantía, un compromiso criptográfico o una referencia de auditoría puede preservar confidencialidad. Lo decisivo es que las condiciones de producción no desaparezcan al tomar la decisión.
Esta es mi propuesta de gobernanza, no una norma de la IETF. Pedir al protocolo que certifique cada sensor sobrecargaría un mecanismo de representación y distribución. Pedir al usuario que deduzca verdad física de una firma válida sobrecargaría la firma.
La “policy mirror” de Heng Lu aclara quién elige y quién hereda el efecto. El mapper escoge fuente y precisión; el xTR o su proxy gobierna la entrega; el Map-Replier firma; quien actúa soporta la consecuencia de una coordenada anticuada o mal fundamentada. El recibo reúne elección y consecuencia. También protege la disciplina del running code: mantener estrecho el formato común y exigir evidencia adicional justo donde el software empieza a ejercer poder institucional.
Fuentes
- Final Review del futuro RFC 10040
- Solicitud AUTH48 de revisión y aprobación
- Texto para autores del futuro RFC 10040
- IETF Datatracker: draft-ietf-lisp-geo
- Historial del Datatracker
- RFC 9303: LISP-SEC
- RFC 6280: arquitectura de ubicación y privacidad
- RFC 6973: consideraciones de privacidad
- RFC 8060: tipo Geo-Coordinate de LCAF
- Registro IANA de tipos LCAF de LISP
- Heng Lu: The Policy Mirror
- Heng Lu: Running Code Primary
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

