Кратко

  • 8 сентября 2026 года RFC Editor зафиксировал одобрение автора и отметил будущий RFC 10040 как готовый к подготовке публикации. 9 сентября документ всё ещё находился на Final Review и ещё не был опубликованным RFC.
  • Новый формат LISP Geo-Location переносит точку, менее точный Geo-Prefix и явное значение неопределённости. Политика доступа, шифрование и подпись LISP-SEC защищают разные этапы распространения.
  • Подпись связывает Map-Reply с подписантом, но сама не доказывает метод и время физического измерения. Системе, принимающей решения по координате, нужна отдельная квитанция о происхождении позиционных данных.

Из редакционной очереди не видно площадку измерения

Событие имеет узкие границы. Final Review для draft-ietf-lisp-geo началось 31 августа. Очередь RFC Editor сообщает, что 4 сентября были получены одобрение Area Director и обновление реестра IANA. 8 сентября одобрение дал Dino Farinacci, после чего появилась отметка «Ready to prepare document for publication». Но на 9 сентября состояние оставалось «In Final Review». Это будущий RFC 10040 с предполагаемым статусом Experimental, а не уже опубликованный RFC и не Proposed Standard.

На этом этапе доводят текст до публикации. Редакционные вопросы решают авторы и RFC Production Center; изменение технического смысла требует одобрения руководителя соответствующего потока. Терминология, ссылка на WGS 84, раздел для ссылки IANA и формулировка о подписи — характерные вопросы конца институционального процесса.

Завершённый вид создаёт особую иллюзию. Если у поля есть номер, двоичная схема и криптографическая защита, все содержащиеся в объекте сведения кажутся одинаково проверенными. Но Map-Reply может быть подлинным и неизменённым, а широта и долгота — остаться утверждением, чья история физического наблюдения находится за пределами протокола.

Тип 17 упаковывает место, но не создаёт наблюдение

Документ определяет Geo-Location type 17 в LISP Canonical Address Format и заменяет прежний Geo-Coordinates из RFC 8060. Запись может содержать Geo-Point или Geo-Prefix. Первый задаёт точку, второй намеренно превращает её в область. Поле Location Uncertainty в сантиметрах описывает неопределённость радиуса и высоты.

Формат делает утверждение богаче, но не раскрывает источник. Координата может поступить от геодезического прибора, GNSS-приёмника, конфигурационного реестра, поставщика данных или ручного ввода. Значение неопределённости тоже может быть результатом расчёта, консервативным запасом или догадкой. Одинаковое поле не делает методы равноценными.

Это граница формата, а не обязательно его изъян. Система позиционирования создаёт наблюдение. Mapper связывает его с EID или RLOC. Map-Replier подписывает получившийся ответ. Словосочетание «подписанное местоположение» склеивает три действия и скрывает, кто отвечает за каждое.

RFC 6280 предлагает разделять позиционирование, распространение и использование. Защита может показать, что получатель увидел именно отправленное создателем, но не подтвердить физическую истинность исходного утверждения. Для координаты внутри картографической и маршрутизирующей инфраструктуры эта архитектурная оговорка становится эксплуатационным правилом.

Подпись отвечает «кто прислал», а не «кто измерил»

Будущий RFC 10040 обычно оставляет решение о доступе локальной политике xTR. Если Mapping Service Provider действует как посредник, он обязан применить политику xTR. Авторизованный запросчик может получить Map-Reply, подписанный по LISP-SEC, и при необходимости зашифрованный. Это серьёзные свойства: аутентификация Map-Replier, целостность и ограничение раскрытия.

Но подпись не сообщает, сделано ли наблюдение пять секунд или пять месяцев назад, калиброван ли датчик, переместился ли объект, допущена ли ошибка ввода и выведен ли радиус неопределённости из измерений. Допуск решает, кто вправе получить утверждение. Он не превращает утверждение в состояние физического мира.

Сам документ признаёт несколько доверительных отношений. Он предупреждает, что координаты позволяют отслеживать хосты, если EID назначаются хостам. Geo-Prefix снижает точность, короткий TTL сокращает срок жизни, аутентификация и политика ограничивают круг запросчиков. Типичное применение относится к публичным сооружениям и ориентирам, а не к людям, транспортным средствам или оборудованию. Эти меры уменьшают раскрытие, но не подменяют происхождение, точность и правила последующего использования, о которых говорит RFC 6973.

Когда координата становится основанием, ей нужна квитанция

Недостающее звено не следует прятать в понятии подписи. Рядом с ответом может передаваться переносимая квитанция. Если оператор, страховщик, служба реагирования, регулятор или автоматический контроллер действует потому, что актив заявлен в определённом месте, он должен видеть цепочку доказательств позиционирования.

Квитанция должна указывать субъект или актив, метод позиционирования, датчик либо исходного поставщика, время наблюдения, систему координат, способ расчёта неопределённости, mapper, подписанта ответа, версию или эпоху политики доступа, условие истечения и результат последующей проверки. Чувствительные сырые трассы необязательно раскрывать всем. Политика может разрешать только класс доверия, криптографическое обязательство или ссылку на аудит. Главное — не отделять условия создания от решения.

Это моё предложение по управлению, а не требование IETF. Если заставить формат картографирования сертифицировать каждый датчик, он выйдет за пределы своей задачи. Если считать подпись сертификатом физической истины, за пределы своей задачи выйдет криптография.

«Policy Mirror» Heng Lu помогает увидеть распределение. Mapper выбирает источник и точность; xTR или посредник управляет раскрытием; Map-Replier подписывает; последствия устаревшей или слабо обоснованной координаты несёт пользователь. Квитанция связывает выбор с последствием. Она сохраняет и дисциплину running code: общий формат остаётся узким, а дополнительное доказательство появляется там, где программа начинает осуществлять институциональную власть.

Источники