Summary

  • The planned-change draft lets a LoST client poll an ordered stream of ChangeSets, identify local civic-location records that may be affected, and validate replacement records for a future asOf time.
  • A future response states what the server knows when it answers. It must be marked NO-CACHE, can change before the effective time, and cannot replace a contemporaneous LoST lookup when a service is actually contacted.
  • Operators need separate receipts for announcement, stream continuity, future validation, local preparation, cutover execution, current mapping, location conveyance, PSAP routing and emergency outcome.

Midnight creates two different truths

At 23:59, an address can correctly belong to one municipality. At 00:00, after a planned annexation or renaming, the same building may need a different civic value. The packet did not move. The legal description of its location did. A Location Information Server must retire one record and activate another without leaving an emergency endpoint between the two.

That is the practical problem addressed by the current planned-change draft. RFC 5222 already lets a client ask a LoST server to validate a civic location and map a location plus service to a service URI. RFC 5139 supplies the civic fields, including administrative elements such as A3. The new proposal adds a way to learn about scheduled changes before they take effect rather than discovering them only through periodic revalidation.

The mechanism is compact. PlannedChangePoll returns identifiers for changes the server knows about. GetChangeSet returns an effective time and partial location elements. A client compares those elements with its own records, prepares replacements, and can ask LoST to validate a location for a future asOf time. revalidateAfter can advise when a current validation should be checked again.

These are useful coordination primitives. None is a certificate of the future.

The protocol marks its own evidentiary limit

The draft says that an asOf answer reflects the server's current understanding of what will apply by the requested time. Two queries for the same future instant can produce different results because the server may learn about another planned or unplanned change. A future mapping must carry expires="NO-CACHE". The client must not assume it will remain unchanged, and it is still expected to use LoST contemporaneously when it actually needs to contact a service.

That is not a defect. It is unusually honest protocol design. It keeps a planning statement in the planning layer.

The same discipline applies to NO-EXPIRATION. That value does not mean an address is immutable. It means the server is not currently aware of a planned change and offers no particular revalidation time. Unplanned changes still exist. Periodic revalidation still matters. The absence of a scheduled change is not proof of permanent validity.

RFC 6443 shows why this distinction matters. Emergency calling is a chain: a device obtains location, LoST maps that location to a service, signalling carries location and a route, proxies and routing functions process the call, and a Public Safety Answering Point receives it. RFC 6881 consequently asks an endpoint to refresh location and attempt a current LoST mapping when an emergency call is made, while defining a cached fallback when timely refresh fails. A successful future validation proves none of those later steps.

A ChangeSet cursor is local memory, not global agreement

The client is expected to retain the last ChangeSet ID it received and ask for later entries. The ID string need not reveal order; the server knows what comes next. A new client, or one that loses its cursor, asks for the changes still retained by that server.

The Security Directorate review exposes the unfinished operational questions. Is the identifier scoped to one server? What happens when two servers issue colliding values? Does a client keep a separate queue for each authority? What happens when authorities disagree about the state that should apply on the same date? The review also notes that the OpenAPI description appears not to provide the later-poll identifier required by the prose.

These questions do not invalidate the proposal. They locate the control surface. A cursor can show a client's position in one server's retained stream. It cannot, without additional scope and reconciliation evidence, show that every relevant authority published the same change, that the client missed no event, or that the resulting local records agree across systems.

The Operations Directorate raised a parallel issue around the proposed XML Schema: the draft says the existing Relax NG schema remains authoritative while offering an easier XML Schema as a non-authoritative alternative and a basis for extensions. If two validation artifacts do not have the same standing, passing the convenient one cannot silently become proof of conformance to the authoritative one.

Build the cutover as a chain of receipts

The first receipt is the announcement: server identity, ChangeSet ID, effective time, partial-location match and the time the client observed it. The second is stream continuity: server scope, previous cursor, returned sequence, retention window and any gap or reset. The third is future validation: request time, asOf, exact input record, returned mapping and NO-CACHE status.

Preparation is a fourth receipt. It records which local rows were selected, which replacements were constructed, which conflicts were found and which cutover was scheduled. Execution is a fifth: the old records actually retired, the new records actually became active, and rollback remained possible. These cannot be collapsed into a green planning dashboard.

The live-service chain begins again at the moment of need. Record the current location, the contemporaneous LoST mapping, the PSAP URI, the service boundary, the location object or reference conveyed, the proxy and emergency-routing path, PSAP receipt, call establishment and operational response. A record can be correct at every earlier stage and still fail at a later one.

This separation follows a basic rule of infrastructure evidence: each system may attest only to the state it owns. A LoST server can answer a mapping query. A LIS can attest to its active records. A proxy can attest to forwarding. A PSAP can attest to receipt. None should borrow the authority of the next system merely because the workflow is continuous.

The proposal is still under evaluation

At the research cutoff, the IESG agenda placed revision 18 on the 24 September telechat. Datatracker showed IESG Evaluation, three DISCUSS positions, a need for additional ballot positions, and an IANA review with unresolved XML-registration questions. The Security Directorate review and Operations Directorate review both reported issues. This is an active Internet-Draft, not an approved RFC, a deployment report or an interoperability result.

That uncertainty is relevant but bounded. The article does not predict the ballot. It identifies the operational question that survives any document state: what exactly does each receipt prove, who owns the next transition, and what evidence remains when the clock reaches the effective time?

Sources

Primary records: current Internet-Draft, IESG agenda, Security Directorate review, Operations Directorate review, RFC 5222, RFC 5139, RFC 6443 and RFC 6881.