Subject: RE: [Ecrit] Issue

From: "James M. Polk" <[email-masked]>
Date: Thu, 22 Dec 2005 18:35:00 -0600

At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote:
>I completely agree with this assessment.
>This is a provisioning requirement.

I agree with James

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
>Of
> > Roger Marshall
> > Sent: Friday, 23 December 2005 10:17 AM
> > To: [email-masked]
> > Subject: RE: [Ecrit] Issue
> >
> > Bringing this one back up for discussion in order to resolve the
>logged
> > issue.
> >
> > Issue 15: Validation of civic location
> >
> > Currently written as:
> > Lo1.  Validation of civic location: It MUST be possible to
> > validate a civic location prior to its use in an actual emergency
>call.
> >
> > Motivation: Location validation provides an opportunity to
> > help assure ahead of time, whether successful mapping to the
> > appropriate PSAP will likely occur when it is required.  Validation
>may
> > also help to avoid delays during emergency call setup due to invalid
> > locations.
> >
> > The following questions were raised from the list, but never
>resolved...
> > "Is this a protocol requirement or an architecture requirement?  When
> > should this validation take place?"
> >
> > My comment:
> > This requirement doesn't really say anything about the mapping
>protocol.
> > We know that all kinds of things are possible prior to an emergency
> > call.  Additionally, we know that the mapping protocol should have a
> > valid location as input to the mapping function in order to be
> > successful.  Nevertheless, I contend that it is not the job of the MP
>to
> > specify this.  If a "non-valid" address is used, it will either map or
> > not map to a URI, in which case an error will result.  One person's
> > architecture may take advantage of this fact, always employ
>validation,
> > and become more robust than next guy's.
> >
> >
> > I say that we should delete this requirement, Lo1.  Other comments?
> >
> >
> > Roger Marshall.
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 22 Dec 2005 21:38:28 -0500

I do not agree, and I'm pretty sure there are a lot of folks who have
experience with emergency calls who would be consider it a fundamental
characteristic of an emergency call system.

You MUST know, before you make a call, that the location you report can be
used to get you help.  That has two uses:
	a) that you can find a valid mapping, which will get your call to
the proper PSAP
	b) that the PSAP can dispatch a responder such that the responder
can find you

To do so, it is required that you validate location before you make the
call.  This is a mechanism requirement, or, if you like, a mechanism design
constraint.

An acceptable mechanism is to allow one to determine prior to a call that a
valid mapping exists.  If the locations used to determine a valid mapping
are those needed for valid dispatch, for which the data may be reasonably
made consistent, and you can do the mapping any time (not just when an
emergency call is placed), that will be minimally acceptable.

Clearly, it would be possible to design the mapping mechanism such that it
could only be used in the process of routing a call.  That would be
unacceptable.  The requirement is necessary to make sure the mechanism can
be used to validate location prior to a call.

The validation is the requirement.

Allowing mapping at any time, and using dispatch-quality data for mapping
input is a solution.

We have found it advantageous to provide for additional capability that is
specific to validation.  For example, it is convenient to allow the
validation function to return multiple valid alternatives when queried with
an invalid location.  So, if you queried for 100 Main Street, there was no
100 Main St, but there was a 100 North Main and a 100 South Main, then we
would like to return both the alternatives when doing validation.  That kind
of response is generally not appreciated when routing a call.  It takes a
human to decide which of the alternatives, if any, is the actual location.  

There are some other desirable functions that could differentiate a
validation request from a mapping request.  There are also operational
differences; one typically re-validates periodically, and every location is
validated.  This means the volume of operations for validation dwarfs the
volume of actual emergency calls.  However, mapping does not have the same
latency or the same reliability constraints.  This may, or may not, be
relevant, depending on the mechanism chosen.

However, North America, and specifically NENA, has a firm requirement for
validation.  It is a current capability.  There is a valid and important
reason for it.  It's clearly implementable.  

For those reasons, I believe it must stand.  We could reword the requirement
and the motivation if that would help.

First, let us see if we can get rough consensus on existence of a validation
requirement.  Then we can work on the wording.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James M. Polk
Sent: Thursday, December 22, 2005 7:35 PM
To: Winterbottom, James; Roger Marshall; [email-masked]
Subject: RE: [Ecrit] Issue 

I agree with James

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Dec 2005 12:54:47 +0100

I find this discussion rather confusing, given the (I hope) generally 
agreed-upon division of labor between the various protocols.

As far as I can tell, the mapping protocol can't tell whether it is 
being invoked immediately as part of a 'real' emergency, after the user 
dials 9-1-1, or just for testing or ahead of a real emergency, e.g., 
when the end system detects a change of location. (This is different for 
call signaling, where one clearly needs to have a "only testing" 
mechanism to avoid causing grief to the PSAP.)

I hope we also agree that the mapping protocol should return good 
indications of what is going wrong, including an indication "address 
does not exist" or "coordinates invalid" or maybe even "warning: you're 
in the open ocean - check that you didn't exchange longitude and 
latitude; here's the coast guard URL".

Since civic-address validation is mainly relevant for stationary and 
nomadic devices, I thought we had also agreed that it's a good design to 
have the device ask for a mapping whenever it changes network attachment 
points and thus possibly change location. In that case, there is no real 
difference between validation and "really" asking.

We had a discussion that there might be some validation mode that 
provides additional error indications. I think this just complicates the 
protocol and introduces possible errors. It's always best to use the 
real thing ahead of an emergency, rather than approximation. Unless we 
want to revive this discussion, there is no requirement item here.

Thus, this whole discussion seems to have a flavor of angels-on-a-pin 
since the traditional distinction between MSAG validation and lookup in 
an PSTN MSAG-style environment just doesn't make sense in our architecture.

There's a separate, but presumably out-of-scope, discussion as to how 
the operator of a mapping service ensures the validity of its database.

Maybe we're not all that far apart if we get away from just throwing 
around old terms like validation and define what we really mean in our 
environment. I suspect part of the disagreement stems from having 
different pictures in mind of how the whole system works. I've said this 
before...

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 23 Dec 2005 08:49:48 -0500

Henning

The problem with your response is that it assumes a particular solution to
the existing requirements.  It may indeed be that the mapping protocol we
select can meet the requirements with no additional work.  If so, great.
However, it is easy to see how you could design the system so that, for
example, mapping could only be done when an emergency call was placed.  I
know your proposal, and indeed all the current proposals, don't do this.
However, the requirement remains a requirement, even if all the proposed
solutions meet it.

With respect to the desirable characteristics of validation to return
alternatives when presented with a bad address, I disagree.

First of all, it would not be a large problem if the system always presented
alternatives when presented with a bad address.  It is clearly the case that
when you make an emergency call, you don't want the system to start giving
you errors and asking for decisions, but consider the alternative.  If you
make an emergency call, and there was a bad address, there are only a couple
of possible results:
	The call is dropped - never a real option
	The call is routed to some kind of default call center
	The system presents you with alternatives and you choose

We're probably going to use the middle one, but we could try the last one if
we had information.  Consider how the call center tries to help you.  First
of all, the call center could be in an entirely different part of the world
than you are.  The address is bad; the default is a default for the service
provider or other entity who attempts the mapping.  That could be half way
around the world.  Specifically, if the database is distributed, there is no
reasonable way the operator of the call center has access to the data in the
mapping database.  What they could do is query it.  They could figure out
that the address is Main, but you meant North Main, but only if they could
do a query to the mapping database that returned the alternatives.  To route
the call, the call center must be able to access the database in exactly the
same way I'm proposing.  It's exactly the same problem the LIS operator or
subscriber has, and the solution is exactly the same.

The thing is, this is a database.  There are standard queries to databases
that get you the kind of alternatives we are talking about.  The only way to
provide alternatives if the mapping protocol doesn't supply them is to build
another protocol to the same database.  It could be a copy of the database,
and if that's the way someone wants to implement it, fine.  I just don't see
any reason NOT to allow a query where a failure gets you alternatives, since
we need something like it when validation fails.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, December 23, 2005 6:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] Issue

Henning

>>> I say that we should delete this requirement, Lo1.  Other comments?
---------------------------------------------------------------------------
> ---------------------
---------------------------------------------------------------------------
> ---------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Dec 2005 15:40:21 +0100

Brian,

I'm not sure how useful it is to write requirements for solutions that 
none of us are working on and we probably can't even envision. I don't 
think the agreement of the three solutions is an accident, but rather a 
consequence of the architectural separation we have assumed. If we have 
the requirement that we allow pre-call lookup, it is a fairly obvious 
consequence to return as much error information as possible.

I don't think we're disagreeing on the second issue. I also believe that 
a reasonable mapping protocol should return both "use this URL if you 
have to do something, this is my best guess given the information you 
gave me" (national or global or regional call center) and "here's a list 
of alternatives that might be better but probably requires human 
intervention to figure out" (Main, North Main, South Main, Maine Street).

I think there is a requirement lurking in your message, namely that a 
third party, such as your global last-hope call center needs to be able 
to issue the same query as the caller even if it is far away from the 
caller. This is because we have no other reasonable way to get these 
alternatives to the call center, as we probably wouldn't want to stick 
those into the signaling protocol.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Fri, 23 Dec 2005 10:12:51 -0500

On Dec 23, 2005, at 6:54 AM, Henning Schulzrinne wrote:

> I find this discussion rather confusing, given the (I hope)  
> generally agreed-upon division of labor between the various protocols.

So long as validation does not impose upon the real work of doing  
mapping during an emergency call (or any pre-routing or whatever), I  
see no problem with having this.

> being invoked immediately as part of a 'real' emergency, after the  
> user dials 9-1-1, or just for testing or ahead of a real emergency,  
> e.g., when the end system detects a change of location. (This is  
> different for call signaling, where one clearly needs to have a  
> "only testing" mechanism to avoid causing grief to the PSAP.)

If the mapping protocol allows for a "this is a test" flag in the  
query, then it can detect the difference.

> indications of what is going wrong, including an indication  
> "address does not exist" or "coordinates invalid" or maybe even  
> "warning: you're in the open ocean - check that you didn't exchange  
> longitude and latitude; here's the coast guard URL".

First, I thought this was about validation of civic addresses.   
Validation of geographical coordinates doesn't seem to be fruitful.   
Just how a mapping server would know that a seeker is truly not in  
the middle of the ocean is beyond me, unless you are suggesting that  
emergencies from water craft are not part of the system.

There certainly could be differences in a query doing validation and  
a query for an emergency call.  During an emergency call, returning  
an error is absolutely not helpful.  During an emergency, if an  
address is not in a system, I hope a URL to a best guess or a default  
would be returned.  But during validation, errors are meaningful.

As Brian has pointed out, I could well imagine a LIS or VSP doing  
audits to make sure customers are able to get the best emergency call  
routing service as possible.

> provides additional error indications. I think this just  
> complicates the protocol and introduces possible errors. It's  
> always best to use the real thing ahead of an emergency, rather  
> than approximation. Unless we want to revive this discussion, there  
> is no requirement item here.

There is a difference between pre-routing and validation.  And if  
something as simple as a validation flag in the query is going to  
complicate the protocol to the point of non-interoperability, then we  
might as well give up now because the act of doing any mapping is  
orders of magnitude more complicated.

-andy