Subject: [Ecrit] Validation for Dispatch in LoST

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Nov 2010 09:57:22 -0500

James Winterbottom pointed out to me this text in RFC5102:
      A caller location is considered valid if the
      civic or geographic location is recognizable within an acceptable
      location reference system (e.g., United States Postal Address or
      the WGS-84 datum) and can be mapped to one or more PSAPs. 
 
In -framework it says:
6.10.  Location validation

   Validation in this context means both that there is a mapping from
   the address to a PSAP and that the PSAP understands how to direct
   responders to the location.  It is recommended that location be
   validated prior to a device placing an actual emergency call; some
   jurisdictions require that this be done.
Notice that the second part ("and can be mapped...") in 5012 is referring to validation for routing, where the text in -framework includes validation for dispatch.  

James claims this is a conflict, which will lead to confusion.  My response is that "recognizable within an acceptable location reference system" is the location reference system in the LoST server, which will be whatever the local emergency authority's deem is needed.  In most cases, that would be valid for dispatch.

I gave James the following examples:
a) There is a building with 2 floor served by one PSAP, and the rest served by another.  This happens.  The 2 floors could be part of a university which has it's own PSAP and responders,  or it could be part of a secure government facility which has a similar situation.  In this case, for a civic address, FLOOR must be present, and valid, in order to route (and to dispatch).
b) There is a building with a large number of floors in a jurisdiction where there is a requirement that location be reported with FLOOR (and often UNIT) if the building is over a certain size limit.  Again, FLOOR would have to be present and valid, even though FLOOR is not needed to route.
c) The LoST server may have FLOOR information, but it may not be a required element.  If the location sent in the LoST request contained FLOOR, but the value was not in the right range, the LoST server should respond with FLOOR in the <invalid> list.  On the other hand, if FLOOR was not present, it wouldn't be an error.

Recall that validation is best done when inserting location information into a LIS; well before an emergency call.  A location suitable for dispatch is also suitable for routing, but a location suitable for routing is not necessarily suitable for dispatch. 

I don't see a problem here.  I think that the "acceptable location system" is determined by the jurisdiction providing the LoST server, and if it requires validation to a dispatchable location, it can reasonably require the LoST server to do that (by suitable provisioning).   -framework says exactly the right thing.

Over in NENA, we are requiring location be valid for dispatch, and we are equipping the LoST server with the information needed to determine that.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 23 Nov 2010 07:13:37 +0800

Hi Brian,

I am sorry that it has taken so long to respond to this, I have been busy with a few other things.

I still have concerns with your proposal here. I think it likely that there will be LoST servers both on the public Internet and in the ESInets. Both of these will be required to do location validation. Location validation in ECRIT has a primary function of ensuring that the location will route to a PSAP. If we take your approach, that LVF must provide a dispatch capable location then things get very murky.

PhoneBCP says: "ED-44 Endpoints SHOULD validate civic locations when they receive

   them from their LCP.  Validation SHOULD be performed in conjunction

   with the LoST route query to minimize load on the LoST server."

If this guidance is followed, and a coarse location provided as is proposed in http://tools.ietf.org/id/-ecrit-rough-loc then the end-point will get an error saying that the location is invalid. Clearly this wrong!

Cheers
James

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, 18 November 2010 1:57 AM
To: ECRIT Org
Subject: [Ecrit] Validation for Dispatch in LoST

In -framework it says:

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 23 Nov 2010 07:29:45 +0800

I think that it might be reasonable to have the device/endpoint determine whether there is a route or not as the primary goal of ED-44 validation.  As long as this is not a default route, then there is no cause for panic.

LoST validation is constrained in what it can report - it’s unclear how a LoST server reports that a civic address is invalid due to missing elements.  In actual fact, the text is written in a way that would seem to exclude this possibility.  If this were possible, a rough location might be reported by the LoST server as having invalid elements (those that might be needed for dispatch), though a value route might still be provided.

That’s some pretty fuzzy specification.  I don’t think that I could reliably implement that given what I know about civic addresses, but it’s the best that I could come up with after thinking more about it.  I suspect that this is why Section 8.4.2 of RFC 5222 is written as it is - such fuzziness isn’t conducive to getting interoperability.

(A concern that I have here is that a device doesn’t have any option to remedy problems with location unless they have alternative sources of location.  -phone-bcp doesn’t specify what a device does if it discovers that the location it has is no good.)

--Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: Tuesday, 23 November 2010 10:14 AM
To: Brian Rosen; ECRIT Org
Subject: Re: [Ecrit] Validation for Dispatch in LoST

Hi Brian,

PhoneBCP says: “ED-44 Endpoints SHOULD validate civic locations when they receive

   with the LoST route query to minimize load on the LoST server.”

Cheers
James

In -framework it says:

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Nov 2010 19:35:27 -0500

I think we are likely to need this in NENA.  It is essential that the North American 9-1-1 system have a location valid for dispatch.  That is the function of the current "MSAG" validation.  This validation has to happen on the public servers.  I believe any system needs this.  You must be able to dispatch a responder with the address that is supplied.  Having some entirely separate validation for dispatch is silly, in my opinion.

The validation that we really need is when a location is entered into the LIS.  This won't be rough - the entity that operates the LIS has the actual location.

The phonebcp validation for rough may indeed fail.   It depends on how it's implemented.  It certainly could be something that is valid, but it doesn't have to be.  I don't think that is a problem.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Nov 2010 19:40:45 -0500

I have asked on this list if the <invalid> list can contain an element not in the original input.  The conclusion of that discussion was that it could.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 23 Nov 2010 08:41:36 +0800

I think this essentially leads to don't do location hiding in the US and Canada because if you do you can't follow the guidance in phoneBCP.
Personally I think that this is a problem, and simply saying let it fail isn't a good option.

________________________________
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, 23 November 2010 11:35 AM
To: Winterbottom, James
Cc: ECRIT Org
Subject: Re: [Ecrit] Validation for Dispatch in LoST

Brian

Hi Brian,

Cheers
James

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, 18 November 2010 1:57 AM
To: ECRIT Org
Subject: [Ecrit] Validation for Dispatch in LoST

In -framework it says:

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Nov 2010 19:44:10 -0500

Also note that the LoST sever could use the "area-representative" method as a hint that dispatch level validation couldn't be done.  I'm still not sure it should say the location is valid; it's not.   Specifically, it does not represent a known location in the local addressing authority's domain.

A way out would be to have a way to say that the location was route valid, but not dispatch valid.  That would add something to LoST.

Brian

On Nov 22, 2010, at 7:35 PM, Brian Rosen wrote:

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Nov 2010 19:45:35 -0500

It's MUCH better than not validating to dispatch quality.

Having a rough location not return invalid is nice-to-have.

Having location validation to dispatch quality is must have.

Brian

On Nov 22, 2010, at 7:41 PM, Winterbottom, James wrote:

> I think this essentially leads to don’t do location hiding in the US and Canada because if you do you can’t follow the guidance in phoneBCP.
> Personally I think that this is a problem, and simply saying let it fail isn’t a good option.
>  
>  
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 23 Nov 2010 09:01:17 +0800

Was that discussion captured anywhere other than in list discussions?

From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, 23 November 2010 11:41 AM
To: Thomson, Martin
Cc: Winterbottom, James; ECRIT Org
Subject: Re: [Ecrit] Validation for Dispatch in LoST

Brian

--Martin

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: Tuesday, 23 November 2010 10:14 AM
To: Brian Rosen; ECRIT Org
Subject: Re: [Ecrit] Validation for Dispatch in LoST

Hi Brian,

Cheers
James

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, 18 November 2010 1:57 AM
To: ECRIT Org
Subject: [Ecrit] Validation for Dispatch in LoST

In -framework it says:

Brian