Summary

  • The RFC Editor recorded author approval on 8 September 2026 and marked RFC-to-be 10040 ready to prepare for publication, but the document remained in Final Review and should not yet be described as a published RFC.
  • Its LISP Geo-Location format can carry points, broader geographic prefixes and an explicit uncertainty value; access policy, encryption and LISP-SEC signatures protect important parts of distribution.
  • A valid signature attributes the Map-Reply to its signer. It does not independently prove how, when or by whom the physical coordinate was observed, so any system that treats the coordinate as evidence needs a separate positioning-provenance receipt.

The last editorial gate exposes the first evidentiary gap

The event is small but precise. Final Review for draft-ietf-lisp-geo began on 31 August. The RFC Editor’s queue records Area Director approval and an IANA update on 4 September, then author Dino Farinacci’s approval on 8 September. Its operational note now says the document is ready to be prepared for publication. As of 9 September, however, the same page still labels it “In Final Review.” It is RFC-to-be 10040, with an intended status of Experimental—not a published RFC and not a Proposed Standard.

That distinction matters because this stage is designed to settle the publication text, not reopen the entire protocol. Editorial questions can be cleared between the RFC Production Center and the authors. A technical change requires the appropriate stream manager. The visible work list—terminology, a WGS 84 reference, the section cited by IANA and wording around signing—shows a document at the end of an institutional process.

But publication readiness can also create a powerful optical effect. Once a field has an assigned number, a polished diagram and a cryptographic protection mechanism, downstream systems are tempted to treat every property in the object as equally verified. RFC-to-be 10040 provides a useful counterexample. The packet can be well formed, the reply can be authentic, and the latitude can still be an assertion whose physical provenance lives elsewhere.

Type 17 packages a place without creating the observation

The document defines LISP Canonical Address Format Geo-Location type 17 and replaces the older Geo-Coordinates design in RFC 8060. A mapping record can describe either a Geo-Point or a Geo-Prefix. The first identifies a point; the second deliberately trades precision for an area. A Location Uncertainty field, expressed in centimetres, can represent radius and altitude uncertainty. These are valuable semantics. They let an operator say more than “here is a latitude and longitude.”

They do not say where the input came from. A location might originate with surveying equipment, a GNSS receiver, a configured inventory record, an upstream commercial feed or an administrator’s manual entry. Those methods produce very different assurance. An uncertainty value is also only as meaningful as the process behind it: a measured confidence interval, a conservative policy envelope and a guessed radius can share the same binary field.

This is not a defect that a format can solve by itself. It is a boundary. The format represents a claim about place. The positioning system creates the claim. The mapper binds it to an EID or RLOC. A signer authenticates the resulting mapping response. Conflating these acts would turn a chain of accountable decisions into one apparently self-proving object.

RFC 6280 supplies the cleanest vocabulary for avoiding that mistake. It treats positioning, distribution and use as different parts of the location lifecycle. A security mechanism can show that a recipient received what a creator sent without proving that the creator’s underlying physical assertion was true. That old architectural warning becomes operationally important when a location field moves into routing and mapping machinery.

The signature answers “who replied?”, not “who surveyed?”

RFC-to-be 10040 places access decisions close to the holder of the mapping. Policy is normally local to the xTR; when a mapping service provider acts as proxy, it must apply the xTR’s policy. An authorized requester can receive a Map-Reply signed as specified by LISP-SEC, and encryption can protect the exchange where deployed. Those controls are substantial. They can authenticate the Map-Replier, preserve reply integrity, restrict disclosure and make unauthorized alteration harder.

None of them is an independent positioning oracle. The signature can bind bytes to a Map-Replier. It cannot disclose whether the location was measured five seconds or five months ago, whether the sensor was calibrated, whether the named asset moved, whether a person transcribed the coordinate incorrectly, or whether the uncertainty radius came from observation rather than convention. Access approval answers who may receive the claim. It does not convert the claim into ground truth.

The document itself does not invite that overstatement. It acknowledges multiple trust relationships and warns that coordinates can help track hosts when EIDs are assigned to hosts. It offers real minimization tools: a Geo-Prefix can blur a point into an area, a short TTL can reduce the life of a mapping, and authentication can limit requesters. Its typical applicability points to public structures and landmarks rather than people, vehicles or equipment. Those choices reduce exposure, but privacy and truth remain separate questions.

Give operational reliance a location-attestation receipt

The missing bridge should not be hidden inside the signature’s meaning. It should be an adjacent, portable receipt. If an operator, insurer, emergency coordinator, regulator or automated controller will act because a LISP record says an asset is in a place, that relying party should be able to inspect the evidence chain for the location claim.

At minimum, the receipt should identify the subject or asset, the positioning method, the sensor or upstream source, the observation time, the coordinate reference system, the method used to calculate uncertainty, the mapper that constructed the record, the signer of the reply, the access-policy version or epoch, the expiry condition and any later verification result. A receipt need not disclose sensitive raw traces to every requester. It can expose assurance classes, commitments or audit references according to policy. The essential point is that the evidentiary fields exist and remain attached to the decision.

This is my governance proposal, not an IETF requirement. RFC-to-be 10040 is defining a representation and distribution mechanism. Asking it to certify every sensor would overload the protocol. Asking every high-consequence consumer to infer physical truth from a valid mapping signature would overload the signature instead.

Heng Lu’s policy-mirror test is useful here: observe which actors obtain a choice and which actors inherit the consequence. The mapper chooses the source and precision. The xTR or its proxy controls disclosure. The Map-Replier supplies the signed object. The relying operator bears the result if an authenticated but stale or poorly sourced coordinate directs an action. A receipt makes that allocation visible. It also preserves the Internet’s running-code discipline: keep the interoperable format narrow, then require evidence at the boundary where software begins exercising institutional power.

Sources