Subject: [Ecrit] lost-planned-changes

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 10 Jul 2015 15:27:01 +0000

The reason there is renewed support for lost-planned-changes is that the NENA guys are getting more and more experience deploying LoST and realize that the number of transactions doing period refresh is much, much more than emergency call transactions, and that setting the period to what you would need to keep up with rapidly growing communities makes the traffic ridiculous.  We need a much better way to know that a location that used to be valid is no longer valid (or will soon be invalid).  Someone asked what was happening to the draft, I told them they I had insufficient interest to progress, and they responded by reading the draft (!) and chiming in.   The people that have sent mail are actively deploying LoST. 

The draft is expired, and it’s short.  I’ll refresh it when the window opens but I’d like to get it adopted and out the door soon.

There will also be a couple of drafts coming that address other interoperability issues discovered in NENA “ICE” events.

Deployment experience is good!  

Brian

---

From: "Sherry, Robert" <[email-masked]>
Date: Fri, 10 Jul 2015 10:59:28 -0600

Just to give a real life example.
Intrado provides a nationwide routing service for VoIP providers.
Currently we get a MSAG from the 911 authority and have a validation database similar to the way E9-1-1 is done.
VoIP providers send us their addresses and we validate them and enter the results in our VPC.

As we move toward NG9-1-1 we are being asked to validate against LVFs.
As you can imagine these VoIP providers have millions of customers (addresses) and in the E9-1-1 scenario addresses were automatically updated when the MSAG changed.
The probability of stale addresses per provider increases with scale.
In the current scenario we would have to be sending 10s of million revalidations monthly to help alleviate the possibility of stale locations.

The ability to notify our systems that a validation has changed would minimize the number of revalidation requests that we would have to perform.

Other potential improvements that would help.
1) A batch process
In E9-1-1 the Service Order system provides batches of addresses to the validation database in a single query.
The response contains the result of the validation for each address.
This provides efficiencies in network capacity.

2) Indication of alternatives
Currently our Data Integrity Unit (DIU) staff manage any fall outs of validation failure.
As we move to NG9-1-1 it would be useful for the LVF to return the "correct" address element or a suggestion of address elements. 

Bob Sherry, ENP 
Intrado Inc.
3030 Warrenville Rd, 4th Floor
Lisle, IL 60532
direct: 630-300-2838   mobile: 630-880-3704
fax: 720-494-6600  email: [email-masked]
 
Intrado
www.intrado.com 

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, July 10, 2015 10:27 AM
To: ECRIT mailing list
Subject: [Ecrit] lost-planned-changes

Brian
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 10 Jul 2015 17:12:07 +0000

Note that -completed-location provides the suggested correct address feature Bob asked for.

We certainly could consider standardized a batch system, which presumably would be a file upload and download.  If we just put the existing mapping request and response as they are currently defined in the files, I would not expect any substantial increase in network efficiency.  If we did something radically different - basically repeating the location information element multiple times and the same with the response validity check response, then you might get some meaningful improvement, but it does seems like it wouldn’t be all that much.    Have to try it and see what it might do.

Brian

> 
> On Jul 10, 2015, at 12:59 PM, Sherry, Robert <[email-masked]> wrote:
> 
>