Re: [Geopriv] NENA Requirements

Martin,

It is actually quite appropriate for the IETF to determine the scope
of its own work. The IETF is not at the beck and call of other
organizations, just as they are not at the beck and call of the
IETF. And we do have the right to question requirements, and it says
a lot if those requirements cannot stand up to scrutiny. And the
IETF does have a right to apply its broad collective of knowledge and
experience on networking to a specific topic area, regardless of how
you feel about any individual's investment in the problem space.

With respect to NENA, it is rude of you to suggest that others on
this list are not respectful towards it. I and several others on this
list are agents of entities that have contributed non-trivial amounts
of funds to NENA so that it may continue its mission. NENA has a
very important role to fill, one which the IETF cannot and will not
take on.

-andy, co-chair of GEOPRIV

On Mar 13, 2007, at 1:55 AM, Dawson, Martin wrote:

> It's actually quite inappropriate for the IETF to be stating what the
> policies for emergency services in global jurisdictions needs to be.
> James' rules below may, indeed, be a strawman but they represent one
> possible set of rules that one possible jurisdiction may wish to
> adopt.
>
> It is an act of hubris for the IETF to deprive jurisdictions of these
> mechanisms because individuals who aren't actually the ones who are
> going to be the stakeholders didn't think it could be handled
> properly.
>
> NENA - who do represent a very broad cross-section of genuine
> stakeholders - do consider that they have the chops to institute
> something like VESA and make it work for them. I have the utmost
> confidence that they will be able to make it work and that it will
> contribute to the integrity, in a significant way, of the emergency
> service. There's a tendency to be dismissive of their skills and
> knowledge in these areas which I think is similarly patronising and
> quite incorrect. They have more experience in making complex networks,
> organizations, and processes work than most of the commentators on
> this
> list. I say give them the tools they are asking for.
>
> Things evolve. In the long term it may actually be considered
> unacceptable for an access network to not provide a robust
> mechanism for
> instantaneous location determination rather than "attachment time"
> location. I suggest that it will always be possible to do this,
> regardless of access technology, given the right approach. Ideally the
> capabilities of networks won't be frozen in time and they will become
> more sophisticated in this respect as time goes by.
>
> On point 4 - you may argue that the "accountability" aspect is not an
> engineering requirement. Perhaps not; it's a service requirement
> and it
> creates the opportunity to provide an engineering solution. There is
> very real value in being able to reliably associate the location with
> the source so that errors in the system can be traced to that
> source and
> corrected. Closing the loop in this way for continuous improvement is
> part of the existing switched circuit telephony emergency service
> processes and there's no less of an imperative for it for IP
> telephony.
> Yet another of the uses of signed location is in providing this robust
> link back to the source for this purpose; it's an engineering solution
> that suggests itself.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Ted Hardie [mailto:hardie@qualcomm.com]
> Sent: Tuesday, 13 March 2007 3:35 PM
> To: Winterbottom, James; Marc Linsner; Dawson, Martin
> Cc: GEOPRIV
> Subject: RE: [Geopriv] NENA Requirements
>
> At 6:44 PM -0500 3/12/07, Winterbottom, James wrote:
>> The 4 requirements I am tabling are below.
>>
>> 1) The only calls that SHALL be directed to a PSAP are those calls
>> that
>> have been made by end-devices that are in the PSAP service
>> jurisdiction
>> at the time a call is made.
>>
>
> This goes contrary to everything we have discussed before, where the
> theory has been that the call taker would try to take a call in any
> circumstance, and these indicators would be used at most for ranking.
>
> To link this to the "warnings" thread on Ecrit right now, we're saying
> there that there will be cases where a server should return a default,
> a stale answer, or similar, because it cannot parse the request,
> cannot
> reach an upstream for the data, or cannot confirm its freshness. It
> returns *a valid PSAP*, even if the request had an unresolvable
> address, because doing so may save lives. Sure, that call should
> have health warnings and may affect the queuing by call takers,
> but saying you won't deliver the call because *you cannot confirm
> at call time that the end device is within the PSAP jurisdiction*
> will
> kill someone. I reject such a requirement utterly, and I hope the WG
> agrees with me. Route the call, and let the local policy at the PSAP
> decide
> if you have to, but failing to route the call via system design is not
> okay.
>
>> 2) Any location used by routing services or subsequent dispatch
> services
>> MUST unequivocally represent the physical position of the end-
>> device at
>> the time the location is proffered.
>>
>
> This is a strawman, or at least I hope it is. A device that got its
> location on
> boot, cannot update it because of network issues, and presents its
> position
> to this system is behaving according to the best-effort nature of
> the underlying network. While the phone system is waiting for me to
> present
> an "unequivocal" location, your strawman is burning up in the car fire
> I was calling to report.
>
>> 3) Any request for location made to a LIS MUST result in either an
>> error, or the current location of the target device being returned.
>>
>
> And if the LIS has the location of the attachment point, but not the
> target device, who resolves the problem? The end node, by presenting
> the attachment point to the LIS for location (nice targeting system,
> good luck!)? Or the LIS, which should return the likely service
> area of
> the
> attachment point as a non-point response? If the latter, we may have
> something useful for identifying useful PSAPs, but it is not the
> target
> device's
> location for lots of systems in which the service area is large
> (think:
> WiMAX).
>
>> 4) The source of the location information MUST be identifiable and is
>> accountable for the accuracy of the information provided.
>
> The second is not an engineering requirement, and the first would be
> satisfied by a self-report for cases like enterprise networks. That
> might well be useful for tracking ill-described locations and similar
> post-facto analyses. But you're sprinkling crypto dust on it in the
> hopes of recreating a system where the underlying mechanism is
> totally different. With enough thrust the pig may fly, but it spoils
> the bacon and irritates the pig.
>
> Ted
>
>> Providing you try to meet these 4 requirements I am happy. Simply
> saying
>> they can't be done and so they are not requirements, as has been said
> in
>> the past, is not acceptable.
>
>
>
>
>
>> Cheers
>> James
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Marc Linsner [mailto:mlinsner@cisco.com]
>>> Sent: Tuesday, 13 March 2007 2:50 AM
>>> To: Dawson, Martin
>>> Cc: 'GEOPRIV'
>>> Subject: RE: [Geopriv] NENA Requirements
>>>
>>> Martin,
>>>
>>>>
>>>> I think all of the NENA requirements have been raised and
>>>> discussed - the latest concept to cause indigestion is
>>>> location signing.
>>>
>>>
>>> You have requirements mixed up with solutions. Signing location
>> objects
>>> is
>>> a solution. I believe Ted nailed the requirement.
>>>
>>> -Marc-
>>>
>>>
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/geopriv
>>
>> ---------------------------------------------------------------------
>> --
> -------------------------
>> 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]
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www1.ietf.org/mailman/listinfo/geopriv
>
>
> ----------------------------------------------------------------------
> --------------------------
> 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]
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 13 Mar 2007 10:23:23 -0400