摘要

  • RFC Editor 在 2026 年 9 月 8 日登记作者批准，并把待发布的 RFC 10040 标为“可准备出版”；但截至 9 月 9 日，它仍处于 Final Review，不能提前称作已经发布的 RFC。
  • 文档让 LISP 映射能够承载地理点、范围更宽的 Geo-Prefix 和明确的不确定度；访问策略、加密与 LISP-SEC 签名分别保护分发环节的重要部分。
  • 有效签名能把 Map-Reply 归于签名者，却不能独立证明坐标如何测得、何时观测、误差半径如何计算。把位置用于现实决策的系统还需要一张定位来源凭据。

出版终点没有消除证据起点

这次状态变化很窄，却很清楚。draft-ietf-lisp-geo 于 8 月 31 日进入 Final Review。RFC Editor 队列记录，主管 Area Director 的批准和 IANA 注册表更新在 9 月 4 日完成，作者 Dino Farinacci 于 9 月 8 日批准，随后备注变为“Ready to prepare document for publication”。与此同时，页面在 9 月 9 日仍写着“In Final Review”。因此它是待发布的 RFC 10040，预定状态为 Experimental，而不是已经出版的 RFC，更不是 Proposed Standard。

Final Review 的制度含义也有限定。编辑性问题可以由 RFC Production Center 与作者澄清；超出编辑范围的技术变更，要交回相应的文档流管理者。当前清单里出现的术语、WGS 84 引用、IANA 所引章节和签名表述，说明文本已在出版车间的末端，而不是重新设计协议的起点。

恰恰在这一刻，读者最容易产生一种错觉：字段有了编号，格式有了精确定义，回复又有密码学签名，于是对象中的每个事实都像被同等核验。RFC-to-be 10040 展示了相反的边界。报文可以合规，回复可以真实来自某个 Map-Replier，经纬度却仍只是一个其物理来源存放在协议之外的主张。

Type 17 能装入地点，不能创造观测

新文档定义 LISP Canonical Address Format 的 Geo-Location 类型 17，并取代 RFC 8060 的旧 Geo-Coordinates 设计。映射记录可以表达 Geo-Point，也可以表达 Geo-Prefix。前者给出一点，后者有意把精度放宽为一个区域。Location Uncertainty 字段以厘米为单位，可以表达半径和高度的不确定度。这比单独传送一对经纬度丰富得多。

但二进制格式不会告诉接收者输入从哪里来。坐标可能来自测绘仪器、GNSS 接收器、资产台账、外部商业数据源，或者管理员手工录入。这些来源的保证强度完全不同。不确定度同样依赖生成过程：基于样本算出的置信范围、出于安全而扩大的政策范围、凭经验填写的半径，都可能进入同一个字段。

这不是靠再加一个格式位就能消除的缺陷，而是职责边界。定位系统产生关于地点的主张；mapper 把它绑定到 EID 或 RLOC；Map-Replier 再对映射回复签名。若把三件事压成一个“已签名位置”，原本可以追责的证据链就会变成一个看似自证的对象。

RFC 6280 早已提供一套合适的拆分法：定位、分发和使用属于位置生命周期的不同阶段。安全机制可以证明接收方拿到的是创建者发出的内容，却不自动证明创建者所称的物理位置是真的。当位置字段进入路由与映射基础设施，这个架构提醒就会变成具体的运营问题。

签名回答“谁回复”，不回答“谁测量”

RFC-to-be 10040 把访问决定放在持有映射的一侧。策略通常由 xTR 本地执行；若 Mapping Service Provider 代为回复，它必须应用 xTR 的策略。获准的请求者可以收到按 LISP-SEC 签署的 Map-Reply，在采用加密时，内容还可获得保密保护。这些控制并非装饰：它们能够认证 Map-Replier、保护回复完整性、限制披露范围，并增加篡改难度。

然而，签名不是独立的定位预言机。它可以把一组字节绑定到回复者，却无法显示坐标是五秒前还是五个月前测得，传感器是否校准，资产是否已经移动，人工转录是否出错，或者误差半径究竟来自测量还是惯例。访问批准回答谁可以收到主张；它不会把主张升级为地面事实。

文档本身并没有鼓励这种夸张解释。它承认存在多重信任关系，也警告：当 EID 分配给主机时，坐标可能帮助追踪主机。它提供了真实的最小化手段——用 Geo-Prefix 把点模糊为区域，用较短 TTL 缩短映射寿命，用认证和访问策略限制请求者。典型适用对象写的是公共建筑或地标，而不是人员、车辆或设备。这些设计能降低暴露，但隐私、来源真实性和物理准确性仍是三个问题。

给现实依赖留一张位置证明凭据

缺少的那一环不应偷偷塞进“签名”的语义，而应成为相邻、可携带的凭据。如果运营商、保险机构、应急协调者、监管者或自动控制器，会因为一条 LISP 记录声称资产位于某处而采取行动，那么依赖方就应能够检查这个位置主张的证据链。

最低限度，凭据应记录主体或资产、定位方法、传感器或上游来源、观测时间、坐标参考系、不确定度计算方法、构造记录的 mapper、回复签名者、访问策略的版本或纪元、失效条件，以及后续核验结果。凭据不必向每个请求者暴露敏感的原始轨迹；它可以依照策略只提供保证等级、密码学承诺或审计索引。关键是这些字段确实存在，并且不会在决策发生时与位置主张脱离。

这是我的治理建议，不是 IETF 的规范要求。RFC-to-be 10040 负责定义表示与分发机制，让它认证所有传感器会使协议不堪重负；反过来，让所有高后果使用者从一个有效映射签名里推断物理事实，也是在让签名承担它从未承诺的任务。

用 Heng Lu 的“政策之镜”去看，问题会更清晰：谁获得选择，谁继承后果？mapper 选择来源和精度；xTR 或其代理控制披露；Map-Replier 交付签名对象；如果一个认证正确但过期或来源薄弱的坐标触发错误行动，承担后果的却是依赖它的运营者。凭据把这种分配照出来。它也保留了“运行代码优先”的纪律：互操作格式保持窄而清楚，软件一旦开始行使制度权力，就在边界上补足证据。

来源