[Ecrit] Dealing with Planned Changes in a LoST server

["Rosen, Brian" <[e-mail]>]

Although we usually think of the data that drives routing and validation stored in a LoST server as relatively static, it’s not completely static.  Things change, slowly, over time.   A good example is “annexation”, which might be known by a different term in countries outside of North America.  Annexation is a process where a municipality “annexes” a portion of the County it is located in, which typically was not part of any other municipality prior to annexation (we would call an area that is not part of a municipality “unincorporated”).

When that happens, the A3 element (Municipality/City name) changes.  Other changes may also occur.   Routing changes also occur, and locations that have the old address could route incorrectly  after the annexation if they are not updated in the LIS.

Annexation is a planned event.  It happens at some time decided upon in advance, and well publicized.  Re-addressing is done, but isn’t effective until the annexation date/time.

What matters to ecrit is that if a location was validated and stored in a LIS with the old A3 (if there even was an A3), the value in the LIS becomes incorrect as of the annexation date.  It needs to be updated, and further, it needs to be updated to a validated content.  The change to the LIS needs to happen coincident with the annexation.

Of course, we have no mechanism to support this in LoST.  The best we can do is recommend to LIS operators that they periodically revalidate the entire content of the LIS.  The frequency of this re-validation is critical, too short and it puts a huge load on the LoST server, too long and bad data persists in the LIS for too long.  And, note that even if the LIS knew the change was coming, it can’t validate the new content until after the annexation.  NENA is very concerned about this issue.   30 day revalidation is a long time to go before discovering a change like an annexation, and yet with 30 days, the load on the server for revalidation is orders of magnitude more than for regular emergency call service.

I have written a draft which addresses this problem by extending LoST in 3 ways:
1. A new element added to <findService> request.  This element, <plannedChange>, has two attributes, a uri and an asOf date.  The uri is stored by the LoST server against the location in the request.  If the location becomes (or, really, will become) invalid, the server will use the uri to push a notification of that invalidation.  The asOf attribute is a date/time value that asks the server to validate as of the date in the attribute, which allows the client to do the validation ahead of the planned change.

2. a <locationInvalidated> object that contains an asOf attribute.  This object is pushed to the uri stored by the server in the case of a planned change.  The asOf attribute specifies when the change becomes effective.

3. A notStored warning that is used by the LoST server to inform the client that although it supplied a uri, the server was unable to store it.  This may occur because of policy in the server, or exceeding a storage limit, or some other condition where the server is unable to store the uri.

The storage happens only on a valid location.

The window is currently closed on submitting drafts, but you can find this at:

https://www.dropbox.com/s/wq9c4t8yn0nhnws/draft-rosen-ecrit-lost-planned-changes-00.txt