Summary

  • RFC 10040 is an IETF-stream Experimental RFC backed by IETF consensus, public review and IESG approval, but it is explicitly not an Internet Standards Track specification. The document says its Experimental category is about technological maturity, not a defined field experiment.
  • The live IANA registry still contains LCAF type 5 as Geo-Coordinates (DEPRECATED) and separately assigns type 17 to Geo-Location. Deprecation is not deletion, and allocation is not evidence that products implement, negotiate, send or parse the new format.
  • A defensible migration record should preserve document status, the old and new codepoints, implementation and peer capability, observed packets, fallback, unknown-type behaviour, privacy and precision policy, failures, corrections and exit conditions as separate facts.

One publication, several different states

The RFC Editor announced RFC 10040 on 15 September 2026. The document updates RFC 8060, deprecates the older Geo-Coordinates encoding identified by LCAF type 5 and defines a more compact Geo-Location encoding under type 17.

That sentence contains at least six states that operators can too easily mistake for one. The LISP Working Group reached a document result. The IESG approved publication on 15 March. The RFC Editor published the final text six months later. IANA coordinated two registry labels. An implementation may or may not support the new encoding. A pair of live nodes may or may not exchange it successfully.

The first four states are now publicly verifiable. The last two require running evidence. None can borrow proof from another.

RFC 10040 makes the first distinction unusually explicit. Its status boilerplate says the document represents IETF community consensus, received public review and was approved by the IESG. The same paragraph says it is not an Internet Standards Track specification and that not every IESG-approved document is a candidate for any level of Internet Standard.

Consensus therefore answers a process question: what text completed the IETF-stream review and approval path? It does not answer whether an operator has deployed type 17, whether two implementations interoperate, or whether an old sender can be retired.

Experimental without an experiment

The most important sentence appears in the introduction. RFC 10040 says the work is not part of an “experiment,” because not every Experimental RFC is necessarily part of an experiment. The label concerns the maturity level of the technology.

That wording blocks two opposite errors. Experimental does not mean “unsafe by definition,” and it does not mean “already being tested in a measured deployment.” It is a document category. RFC 7841 supplies the standard description: an Experimental document is published for examination, experimental implementation and evaluation. It does not supply the hypothesis, cohort, telemetry, duration or success threshold for a particular operating trial.

The distinction matters because a maturity label is easy to display while evidence is expensive to collect. A release note can repeat “Experimental.” A migration plan must name software versions, peer capabilities, packet paths, fallbacks, observation windows and decisions. Treating the label as the plan would allow the cheapest evidence to impersonate the hardest work.

Nor should IETF consensus be used to erase the debate that preceded approval. The public history contains questions about prior implementations, deployment need, privacy, location precision and the lack of a conventional experiment definition. The final RFC is the approved outcome. The history is evidence of reviewed uncertainty, not a licence to claim that every question has an operational answer.

Deprecated does not mean gone

The live IANA LISP parameters registry makes the transition visible. Type 5 remains listed as Geo-Coordinates (DEPRECATED), with references to RFC 8060 and RFC 10040. Type 17 is listed separately as Geo-Location.

That is a change in preferred protocol vocabulary, not a deletion event. RFC 10040 does not say type 5 vanished from the registry, that every receiver must now reject it, or that every sender has moved. The registry preserves the old identifier precisely because deployed code and recorded protocol history cannot be made to disappear by reusing the number.

This is where deprecation creates work rather than finishing it. A sender that emits only type 17 needs a reason to believe the receiver can use it. A receiver may support the new format for RLOC records but lack the registration or lookup behaviour required for EID records. A fleet may contain several software versions. A controller may serialize the new body while an observation tool, export path or downstream validator still assumes type 5.

RFC 10040 does not define a universal capability-negotiation exchange for this transition. Operators therefore need to record how support was established: configuration, version inventory, bilateral profile, test exchange, controlled rollout or another bounded method. Silence is not capability.

The compatibility clause is an operational warning

Section 8 draws an asymmetric boundary. Geo-Location EID records are supported only by LISP nodes that support them for registration and lookup. Geo-Location RLOC records can be returned to nodes that do not understand them; in that case, the RLOC record is ignored.

Ignoring an unknown type can be safe protocol behaviour and still be a failed service outcome. A sender can produce a valid type 17 body, a mapping system can carry it, and a receiver can correctly ignore it. Every component may be behaving according to its local rule while the location-dependent function never occurs.

That chain defeats three tempting shortcuts. A clean registry entry does not prove a parser exists. A successful send does not prove the receiver used the record. A parse event does not prove an application selected a route, answered a lookup or made a location-dependent decision.

Migration evidence must therefore be directional. It should identify which component emitted which type, which peer received it, how the peer classified it, whether the record was used or ignored, and what fallback preserved service. “Supports RFC 10040” is too broad to diagnose a mixed fleet.

More precise fields do not make a location true

Type 17 changes more than its number. It adds explicit location uncertainty, millisecond components for latitude and longitude, units for altitude, and a radius that distinguishes a Geo-Point from a Geo-Prefix. These are useful representation rules. They improve what an implementation can encode consistently.

They do not certify the source of the coordinates. A location with centimetre-granularity fields may still come from a stale inventory, a manual error, a broad estimate or a device whose actual accuracy is much lower. The uncertainty field can carry a claim about precision; it is not an external measurement of truth.

The same limit applies to authority. RFC 10040 discusses local policies over who may access mapping records, proxy enforcement by a Mapping Service Provider, signed or encrypted replies, Geo-Prefixes as data minimisation and short TTLs to reduce the attack window. It says typical use concerns public structures, places and landmarks rather than people, vehicles and equipment.

Those safeguards have to be configured and observed. The appearance of coordinates in a packet proves neither consent nor access authorization. A valid signature can identify or authorize a responder under a stated mechanism; it does not prove that the underlying location is correct, that the subject agreed to disclosure, or that a downstream recipient retained it lawfully.

A maturity-and-migration receipt

The smallest useful record is not a single compliance flag. It is a versioned receipt joining three layers without merging them.

First is document provenance: IETF stream, Experimental category, IESG approval date, RFC publication date, RFC 8060 Section 4.3 as the updated text, type 5 as the deprecated identifier and type 17 as the new assignment. Any future status change or erratum should appear as a new dated fact, not as a rewrite of the original record.

Second is compatibility and migration: implementation and version; supported record roles; method used to establish peer capability; encoding actually emitted; encoding actually parsed; unknown-type result; dual-encoding or fallback window; test scope; failure count; correction owner; rollback and retirement criteria. If an operator temporarily accepts both types, the receipt should state whether that means parse-only compatibility, production use, or active fallback.

Third is location-data use: provenance of the coordinates; claimed and measured precision; use of Geo-Point or Geo-Prefix; access-control policy; authorization mechanism; retention or TTL; observation scope; downstream consumers; correction route; and the decision that allows or refuses operational use.

The receipt should never turn absence of evidence into a red status invented by a dashboard. “Not observed,” “not tested,” “not supported,” “ignored” and “failed to parse” are different states. So are “deprecated,” “disabled,” “retired from one fleet” and “removed from a registry.”

This follows a simple running-code discipline. Publication creates a shared coordination artifact. Reality changes when implementations adopt it, peers interoperate and operators accept the effects. A registry can coordinate a number; it cannot manufacture the packet that number is meant to identify.

Sources and limits

The principal evidence is RFC 10040, the RFC Editor publication notice, the Datatracker history, the IANA LISP parameters registry, RFC 8060, RFC 7841 and RFC 6973. The RFC 10040 errata query returned no matching records at the 21 September 2026 cutoff.

These sources establish document, registry and protocol semantics. They do not provide a complete implementation-support matrix, deployment census, packet trace, migration schedule, location-accuracy audit or consent record. The absence of such evidence here is a boundary on this article, not proof that no implementation or deployment exists.