Subject: RE: [Ecrit] Issue

From: "James M. Polk" <[email-masked]>
Date: Fri, 23 Dec 2005 02:29:47 -0600

At 11:01 PM 12/22/2005 -0600, Winterbottom, James wrote:
>Brian,
>
>No one is arguing that this needs to be done ahead of time. This is why
>it is a provisioning issue and not a call routing issue. So it is out of
>scope.

Brian

I agree with James here.

You (Brian) use the word "you" too many times below for me to figure out 
who "you" is in what you (Brian) mean.

You pose the scenario in which I do (not can, but do) a query for my 
location to determine *if* my emergency call, *if* I ever make one, *will* 
go to the proper PSAP.

I don't believe 99% of us will walk off a plane and check this piece of 
information *every time*  any one of us walks off a plane; and we're 
dealing with emergency communications.  This is *not* part of today's 
societal behavior to validate a location in their phone will reach an 
appropriate PSAP, and I'm believing it will never be.

Just think about Letterman tapping an assistant asking a series of people 
on a major NYC street "do you know what PSAP is your correct PSAP where you 
are standing now?" or "Do you know the correct PSAP for your home?" How 
many of those people do you think will get that answer right, and how would 
they know they're right or wrong? Is the network that's giving them false 
information going to tell them it's false all the time?

Pick a Application SP (for lack of a better term) and ask them what a user 
of their network does *if* their IP phone points at a PSAP that is not 
correct? Who does that user call? The App SP? How many people will be 
employed to do this work? What's the size of that call center?  How 
profitable will that department be?  How long will a person wait on hold 
before they giving up and not bothering to correct the problem?

Someone needs to do in the background all that can be done to ensure an 
emergency call is routed correctly, but this is based on information that 
was delivered or configured in the endpoint. It was not interactively 
checked by the human user before proceeding.

This is an operational requirement, which is out of scope for ECRIT

> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Friday, 23 December 2005 1:38 PM
> > To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall';
>[email-masked]
> > Subject: RE: [Ecrit] Issue
> >
> > 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
> >
> > 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
> >
> >
>
>------------------------------------------------------------------------------------------------
>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

---

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

You (James) are slightly confused.

I assure you that there are indeed many people with enough experience with
the emergency call system, both in North America, and elsewhere, who would
like the ability to test to see if a call will work before they make it.

However, that's not the major use of validation.

The major use of validation is for LIS operators.  Before an entry is put in
the LIS, it is validated.

Now, what we have today for VoIP is self reporting.  The LIS is run by the
VoIP operator, and the human that puts the address in is a subscriber.   The
LIS validates the entry when the subscriber types it in, and the LIS let's
the subscriber know if he has given it a bad address.

What we want to get to is automatic location, where the access network
supplies location.  In this case, the validation is done as part of
provisioning the LIS.  When the entry to the LIS (which is usually some
association of a service address and a circuit ID) is made, validation is
required.  In this case it's usually part of some service order processing
at an access carrier.  Now, that may be provisioning to the LIS, but it's an
operational query to the mapping system.

To the mapping system, these queries are run time operations.  Depending on
how we implement mapping, they may be indistinguishable from actual
emergency call routing queries.  The query comes from an entity that is
different (in most cases) from the entity running the mapping service.  It
requires a real time response.  That seems like a clear requirement, and
it's in scope.

Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, December 23, 2005 3:30 AM
To: [email-masked]
Cc: Winterbottom, James; Roger Marshall; [email-masked]
Subject: RE: [Ecrit] Issue 

Brian

I agree with James here.