Subject: RE: [Ecrit] Issue

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 22 Dec 2005 23:01:56 -0600

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.

> -----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:22:07 -0500

This is not a provisioning issue, at least not a provisioning issue for the
mapping database.  In some circumstances, it's a provisioning issue for a
LIS, but with respect to the mapping protocol, it's an operational
requirement.

Repeating myself, the requirement is that ecrit provides a mechanism to
confirm the validity of an address.  Validity in this case means:
	If the address was to be used for an emergency call, it would be
recognized in the database and a valid mapping would be returned
	If the address was used for dispatch, it is an address that the
responders would recognize and be able to send help

We can meet the requirement, minimally, by permitting mapping at any time,
and by control of the data used for mapping.  It is desirable, but not
essential, to do more.

Brian

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

Brian,

[email-masked]
can be
to
responder
the
that
mapping
reasonably
that it
can
mapping
that is
was no
we
That
takes a
location.
location
the
same
for
important
Of
Behalf
Validation
invalid
When
emergency
a
MP
map or
person's
comments?
--
--

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: Ted Hardie <[email-masked]>
Date: Fri, 23 Dec 2005 12:37:51 -0800

>responders would recognize and be able to send help

Thanks for very clearly separating those two out.  The first actually breaks into
two cases:  1) there is enough data provide a mapping, but the data are incomplete
or incorrect in some way known to the system; 2) the data are correct and complete
and in some way known.

How often case one happens depends a lot on the way in which the locality has organized  its PSAPs.  If a municipality has a single PSAP, a correct mapping can be
returned if there is a municipality in the location object, even if no other data is present.
There are lots of other cases where partial information or partially correct information
can still be sufficient to generate a good mapping; as long as you do not presume that the query is hamstrung to be exact-match only, good results can come from incomplete data in non-trivial numbers of cases.
 
What you want to return to a query in the case of "available mapping, but a location object that is incomplete" depends on whether the query is associated with an actual emergency or is specific to validation.

If the query being made is specifically a validation query, it should return the mapping and an indication that the data is not complete (or elements are not correct); if
the query is an emergency query, it should simply return the mapping.  Distinguishing
between the two cases with a query flag is an obvious choice, and I think most of us believe that's a good thing to do.

Going beyond that to your second case, there is a question about whether what validation query is testing against is the address's correctness/completeness
for dispatch. I think it is logical to assume it is. 

I *think* then, what the requirement boils down to is that the error results for
negative returns to validation queries should  distinguish among location objects
that are too incomplete for dispatch, those that are complete but appear to have data
that is not in the database, and those in which the data are known to be wrong (cites a
floor in a building higher than is possible, for example). 

We could go beyond that, to citing which data elements are known to be wrong, and there are cases where we might be able to cite which data elements are missing (though this gets complicated fast, as you will run into lots of "Must include either municipality or county name with a street address).  I personally suspect punting that
level of specificity to a free text field is okay; you'll only get it when validating an
address, and the most valuable data may actually be who to call to work out the
problem (rather than possibly difficult to interpret data).

				regards,
					Ted Hardie