|
|
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:James.Winterbottom@xxxxxxxxxx]
Sent: Friday, December 23, 2005 12:02 AM
To: br@xxxxxxxxxxxxxx; James M. Polk; Roger Marshall; ecrit@xxxxxxxx
Subject: RE: [Ecrit] Issue
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:br@xxxxxxxxxxxxxx]
> Sent: Friday, 23 December 2005 1:38 PM
> To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall';
ecrit@xxxxxxxx
> 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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] On Behalf
Of
> James M. Polk
> Sent: Thursday, December 22, 2005 7:35 PM
> To: Winterbottom, James; Roger Marshall; ecrit@xxxxxxxx
> 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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] On
Behalf
> >Of
> > > Roger Marshall
> > > Sent: Friday, 23 December 2005 10:17 AM
> > > To: ecrit@xxxxxxxx
> > > 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
> > > Ecrit@xxxxxxxx
> > > 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
> >Ecrit@xxxxxxxx
> >https://www1.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
> 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
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|