Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered

[Brian Rosen <br at brianrosen.net>]

Nope, your UK provider can correctly route.  Actually, if your phone is
phonebcp compliant, all that means is the service provider forwards the call
where the phone is trying to send it (to the ESRP learned from the ECRF).
Assuming the UK provider gets the location from the phone (in the
Geolocation header), it could route, or, perhaps more relevant, it can
verify the route. There is no need to send it through a U.S. Service
provider, who couldn't help us at all.

And the UK provider may well be able to help.  We want to know about them.
They may have information that is useful.

As was discussed a few messages ago, it may be that the UK service provider
has an identity that the UK emergency call authorities trust.  We may be
able to arrange that the US emergency call authorities can figure out that
the UK trust relationship is in place, and transitively trust the UK
provider, even though it has no relationship with that provider.  This might
be as simple as a signature on a cert by the UK authorities that the US
authorities can verify simply by having access to the (presumably well
known) UK CA cert.  I think we will have such certs available for US service
providers if other emergency authorities wish to use similar mechanisms.

Brian

On 10/30/09 12:53 PM, "Elwell, John" <john.elwell at siemens-enterprise.com>
wrote:

> Brian,
> 
> So suppose my SIP-PBX is in the UK and uses a VoIP service provider in the UK.
> I am in a hotel in the US and make an emergency call using a device that uses
> my SIP-PBX in the UK as its outbound proxy. From the location determined by my
> device, the call needs to go to a PSAP in the US. Will routing via the UK
> service provider really help? It seems unlikely that the UK service provider
> would have an arrangement with a US PSAP. So perhaps the UK provider could
> route it on to a US provider, which hopefully would have such an arrangement.
> This round-about routing seems to increase the chances of failure.
> 
> It seems what is really needed in this situation is either:
> - routing directly from the SIP-PBX in the UK to the US PSAP; or
> - my device sends the call directly to the US PSAP.
> 
> John
> 
>> -----Original Message-----
>> From: Brian Rosen [mailto:br at brianrosen.net]
>> Sent: 30 October 2009 14:07
>> To: Elwell, John; Marc Linsner
>> Cc: ecrit at ietf.org
>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
>> considered
>> 
>> Well, yes.
>> 
>> Normally, your SIP-PBX would route calls outside the domain
>> to some kind of
>> carrier.  That is what I want it to do, but I can foresee
>> circumstances
>> where the PBX sends calls to the ESRP.  I would like the ESRP
>> to know about
>> the PBX (that is, have it's identity in some list it has, one way or
>> another, so that when it lowers priority of calls from
>> unknown sources,
>> those calls are not lowered.  I think such arrangements will
>> be uncommon,
>> but possible.
>> 
>> Brian
>> 
>> 
>> On 10/29/09 5:28 AM, "Elwell, John"
>> <john.elwell at siemens-enterprise.com>
>> wrote:
>> 
>>> Brian,
>>> 
>>> Just a question for clarification below:
>>> 
>>>> -----Original Message-----
>>>> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>>>> On Behalf Of Brian Rosen
>>>> Sent: 29 October 2009 03:18
>>>> To: Marc Linsner
>>>> Cc: ecrit at ietf.org
>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
>>>> considered
>>>> 
>>>> I'm not worried about security by obscurity.  I don't want
>>>> phones (or other
>>>> devices) built to call directly.
>>>> 
>>>> -phonebcp says "send the call on your normal outbound call
>>>> path".  That's
>>>> what I want it to say, and I don't want it to say "send it
>>>> direct, bypass
>>>> your service provider.
>>> [JRE] So if my normal outbound call path is my SIP-PBX,
>> then the SIP-PBX can
>>> route directly to the PSAP?
>>> 
>>> John
>>> 
>>> 
>>>> 
>>>> I'm not stopping attack, I am stopping abuse.
>>>> 
>>>> I don't want devices that are not subscribed to services to
>>>> be able to make
>>>> emergency calls (that is, if they can't make "normal" calls,
>>>> they should not
>>>> be able to make emergency calls).
>>>> 
>>>> Brian
>>>> 
>>>> 
>>>> On 10/28/09 6:51 PM, "Marc Linsner" <mlinsner at cisco.com> wrote:
>>>> 
>>>>> Brian,
>>>>> 
>>>>> What I hear you saying: 'if we don't document how to spoof
>>>> a PSAP, then
>>>>> nobody will figure it out.'  Isn't that a little short sighted?
>>>>> 
>>>>> Joey at miscreant.org will figure out how to establish a SIP
>>>> session with any
>>>>> PSAP in the world within 10 minutes of that PSAP being
>>>> accessible via the
>>>>> Internet, regardless of documentation.
>>>>> 
>>>>> I believe there's more harm created in not documenting this for
>>>>> John.Q.Public at ordinary_citizen.com.
>>>>> 
>>>>> Granted, nobody here is looking to cause harm to a PSAP.  But
>>>>> Joey at miscreant.org can certainly expend public safety
>>>> resources by reporting
>>>>> a bomb threat to a local school.  Should we require that
>>>> all SIP calls to
>>>>> the local school come from a trusted SP?  Where does it end?
>>>>> 
>>>>> This isn't the way to deal with spam.
>>>>> 
>>>>> -Marc-
>>>>> 
>>>>> 
>>>>> 
>>>>> On 10/27/09 11:00 AM, "Brian Rosen" <br at brianrosen.net> wrote:
>>>>> 
>>>>>> The first goal is to prevent bad calls.
>>>>>> 
>>>>>> The second goal is to indentify the source of the bad calls.
>>>>>> 
>>>>>> I'm starting with the first goal.  I don't want you to be
>>>> able to take a
>>>>>> device out of a box, plug it into a network, and have the
>>>> only call you can
>>>>>> make be an emergency call.  I want the device to actually
>>>> "work" (as in be
>>>>>> able to place calls to all the entities that it was
>>>> intended to) first, and
>>>>>> then be able to place emergency calls.
>>>>>> 
>>>>>> Please spend some time in a PSAP while a kid with a
>>>> simless phone has "fun"
>>>>>> with it.  Imagine how much fun the test mechanism is as
>>>> opposed to placing
>>>>>> real calls.
>>>>>> 
>>>>>> If we somehow get a bad call, we need to send the cops.
>>>> That means we need
>>>>>> an identity (and a location).
>>>>>> 
>>>>>> I think a good cert could be the basis of a good identity,
>>>> if we could get
>>>>>> one.  I don't see how we do that.
>>>>>> 
>>>>>> Brian
>>>>>> 
>>>>>> 
>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" <rbarnes at bbn.com> wrote:
>>>>>> 
>>>>>>> Brian,
>>>>>>> 
>>>>>>> Is the security goal here more access control (i.e.,
>>>> controlling who
>>>>>>> can send calls to a PSAP) or attribution/identification
>>>> for post-hoc
>>>>>>> action.
>>>>>>> 
>>>>>>> If it's the latter, then ISTM that the problem can
>>>> largely be reduced
>>>>>>> to having a certificate infrastructure that binds authenticated
>>>>>>> identities to real-world entities.  The "extended validation"
>>>>>>> certificates that current commercial CAs issue seem to
>>>> largely satisfy
>>>>>>> this requirement.
>>>>>>> 
>>>>>>> --Richard
>>>>>>> 
>>>>>>> 
>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote:
>>>>>>> 
>>>>>>>> Of course not all VSPs will have trust relationships with all
>>>>>>>> PSAPs.  One
>>>>>>>> can hope that long term, we can evolve to transitive trust
>>>>>>>> relationships
>>>>>>>> that work pretty well cross border.
>>>>>>>> 
>>>>>>>> The emergency guys are actually terrified of private/individual
>>>>>>>> domains
>>>>>>>> sending them calls, and we're telling them we expect that to be
>>>>>>>> possible,
>>>>>>>> but rare, and we're giving them mechanisms that will
>> effectively
>>>>>>>> allow them
>>>>>>>> to turn off calls selectively, based on factors including what
>>>>>>>> domain the
>>>>>>>> call comes from.  They expect that such calls will be
>> one of the
>>>>>>>> loopholes
>>>>>>>> where they get equivalents to sim-less calls, which drive them
>>>>>>>> nuts.  They
>>>>>>>> don't want ANY calls that don't come from service providers,
>>>>>>>> although they
>>>>>>>> seem to be okay with the notion that the SP may not have great
>>>>>>>> identity (AOL
>>>>>>>> being a poster child).  So, while indeed they
>>>> understand, and have
>>>>>>>> concerns
>>>>>>>> about having to take calls from Sierra Leone VoIP
>>>> services Pty, they
>>>>>>>> would
>>>>>>>> much rather have a call that went through them then a
>>>> call that went
>>>>>>>> through
>>>>>>>> no service provider at all.
>>>>>>>> 
>>>>>>>> I'm not trying to make calls direct from devices or
>>>> private domains
>>>>>>>> impossible, but I think the notion that we're
>> promoting them is a
>>>>>>>> very bad
>>>>>>>> idea until we have effective mechanisms to prevent abuse.
>>>>>>>> 
>>>>>>>> Brian
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" <mlinsner at cisco.com> wrote:
>>>>>>>> 
>>>>>>>>> Brian,
>>>>>>>>> 
>>>>>>>>> I'm a little confused.  I don't remember you objecting to
>>>>>>>>> requirement RE1
>>>>>>>>> from RFC5012 and I remember your use case about a
>>>> Sierra Leone VSP.
>>>>>>>>> 
>>>>>>>>> Are you implying that *all* VSPs will have a trust
>> relationships
>>>>>>>>> with *all*
>>>>>>>>> PSAPs?
>>>>>>>>> 
>>>>>>>>> What is the difference between a call coming from a private/
>>>>>>>>> individual
>>>>>>>>> domain (as in not a commercial VSP) and a VSP on the
>>>> other side of
>>>>>>>>> the world
>>>>>>>>> (outside the jurisdiction)?
>>>>>>>>> 
>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous
>>>>>>>>> calls to the
>>>>>>>>> PSAP or the mechanisms proposed in this draft?
>>>>>>>>> 
>>>>>>>>> [Don't take this as my endorsement of the draft, as I'm
>>>> not sure I
>>>>>>>>> agree
>>>>>>>>> with UAs registering with the ESRP.]
>>>>>>>>> 
>>>>>>>>> -Marc-
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" <br at brianrosen.net> wrote:
>>>>>>>>> 
>>>>>>>>>> First of all, I put it on the wrong email list, sorry
>>>> about that.
>>>>>>>>>> 
>>>>>>>>>> Then, we have carefully arranged it so that there is
>>>> no identity
>>>>>>>>>> coming from
>>>>>>>>>> the access network provider, and because the
>> location is coming
>>>>>>>>>> from that
>>>>>>>>>> provider, we really don't want to.  But even if we
>>>> did, we would
>>>>>>>>>> need a
>>>>>>>>>> really good identifier, and there isn't one.
>>>>>>>>>> 
>>>>>>>>>> The problem we have with -direct is anonymous callers,
>>>> and if they
>>>>>>>>>> have any
>>>>>>>>>> option, they would also be location-less.  Until and
>>>> unless we get
>>>>>>>>>> rid of
>>>>>>>>>> anonymity, we can't encourage service provider-less
>> calls.  The
>>>>>>>>>> draft does
>>>>>>>>>> not make any provision to provide any kind of identity.  Many
>>>>>>>>>> networks
>>>>>>>>>> (think free wifi for example) would make providing
>>>> good identity
>>>>>>>>>> difficult.
>>>>>>>>>> 
>>>>>>>>>> The fact is that there is a SERVICE provider in nearly
>>>> all of the
>>>>>>>>>> communications systems.   The SERVICE provider is in a
>>>> position to
>>>>>>>>>> assist
>>>>>>>>>> the emergency calling system when it needs more information.
>>>>>>>>>> That's what a
>>>>>>>>>> good SERVICE provider does.  Cutting them out is not a great
>>>>>>>>>> idea.  Most of
>>>>>>>>>> the attempts to provide real time communications
>> between people
>>>>>>>>>> have evolved
>>>>>>>>>> to using service providers, even when there were
>>>> alternatives.  File
>>>>>>>>>> transfer via something like Torrent is a
>> counterexample (which
>>>>>>>>>> isn't real
>>>>>>>>>> time), but even there, you end up with service
>>>> providers like The
>>>>>>>>>> Pirate Bay
>>>>>>>>>> (R.I.P) to provide introduction services.  I don't
>> think we're
>>>>>>>>>> going to see
>>>>>>>>>> changes that eliminate service providers, and in this
>>>> case, they
>>>>>>>>>> provide
>>>>>>>>>> value to the emergency calling systems.  All of the emergency
>>>>>>>>>> professionals
>>>>>>>>>> I know have issues with service providers, but they
>> would react
>>>>>>>>>> with horror
>>>>>>>>>> if you suggested cutting them out.  Ask them, please.
>>>>>>>>>> 
>>>>>>>>>> So, I claim you have a solution in search of a
>>>> problem.  We have
>>>>>>>>>> solved the
>>>>>>>>>> "calling network isn't the access network" problem
>>>> already.  Service
>>>>>>>>>> providers ARE in the path now, in nearly every case
>> (in fact a
>>>>>>>>>> counter
>>>>>>>>>> example escapes me, although there probably are some).
>>>>  There is
>>>>>>>>>> no movement
>>>>>>>>>> I can detect which would change that any time soon; quite the
>>>>>>>>>> opposite.  We
>>>>>>>>>> have a known killer problem without some kind of
>>>> subscription to a
>>>>>>>>>> service
>>>>>>>>>> that provides a good identity, for which you provide
>>>> no answers.
>>>>>>>>>> We have
>>>>>>>>>> experience with the killer problem: sim-less calling
>>>> was supposed
>>>>>>>>>> to provide
>>>>>>>>>> a way to make an emergency call in exactly the kinds of
>>>>>>>>>> circumstances you
>>>>>>>>>> are describing.  Our real world experience is that
>> you create a
>>>>>>>>>> huge problem
>>>>>>>>>> that diverts resources from helping people to chasing
>>>> scammers and
>>>>>>>>>> flea-market sellers.
>>>>>>>>>> 
>>>>>>>>>> Nothing is perfect: you can get a AIM screen name
>>>> without a very
>>>>>>>>>> good
>>>>>>>>>> identity for example.  However, the notion that
>> we're going to
>>>>>>>>>> provide
>>>>>>>>>> direct access without a service provider deliberately,
>>>> especially
>>>>>>>>>> without
>>>>>>>>>> really good identity from the access network is, in my
>>>> opinion not
>>>>>>>>>> only a
>>>>>>>>>> no, it's a heck no.  I'll line up as many emergency service
>>>>>>>>>> professionals as
>>>>>>>>>> you would like to tell you this is a harmful idea.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin"
>>>> <Martin.Dawson at andrew.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I am glad this has come up. It's a debate that has to
>>>> happen if
>>>>>>>>>>> we are to
>>>>>>>>>>> move
>>>>>>>>>>> beyond a long standing legacy misconception.
>>>>>>>>>>> 
>>>>>>>>>>> In the circuit service world - whether it was POTS or
>>>> mobile, the
>>>>>>>>>>> access
>>>>>>>>>>> network had full responsibility for delivering the emergency
>>>>>>>>>>> call. In that
>>>>>>>>>>> world, routing an emergency call meant getting a circuit
>>>>>>>>>>> established to the
>>>>>>>>>>> correct call center. In most parts of the world,
>> this was done
>>>>>>>>>>> using the
>>>>>>>>>>> regional part of the PSTN to switch the circuit to a
>>>> call center
>>>>>>>>>>> on the
>>>>>>>>>>> PSTN.
>>>>>>>>>>> In some jurisdictions, such as the US, it was done
>>>> directly from
>>>>>>>>>>> the local
>>>>>>>>>>> exchange carrier to the call center. Either way,
>> there was no
>>>>>>>>>>> third party
>>>>>>>>>>> involved.
>>>>>>>>>>> 
>>>>>>>>>>> Now we have the Internet. We still have public
>> access network
>>>>>>>>>>> providers.
>>>>>>>>>>> They
>>>>>>>>>>> switch packets onto the Internet for their
>>>> subscribers. They can
>>>>>>>>>>> similarly
>>>>>>>>>>> ensure that packets reach the local emergency call centers.
>>>>>>>>>>> 
>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the
>>>>>>>>>>> traditional
>>>>>>>>>>> environment. VoIP is a presence service, and it had
>> no common
>>>>>>>>>>> equivalent in
>>>>>>>>>>> the PSTN world. It could have, but the narrowband state of
>>>>>>>>>>> technology and
>>>>>>>>>>> the
>>>>>>>>>>> common market use cases didn't support its
>> development. By the
>>>>>>>>>>> time ISDN
>>>>>>>>>>> arrived, the PSTN had already slipped into its
>>>> palliative stage
>>>>>>>>>>> without
>>>>>>>>>>> realizing it.
>>>>>>>>>>> 
>>>>>>>>>>> It's an entrenched misconception that because the
>>>> circuit service
>>>>>>>>>>> provided
>>>>>>>>>>> by
>>>>>>>>>>> exchange carriers was most commonly used for
>> "voice" (but, it
>>>>>>>>>>> should be
>>>>>>>>>>> noted,
>>>>>>>>>>> also for fax, telex, tty, security system monitoring
>>>> and, even,
>>>>>>>>>>> IP data)
>>>>>>>>>>> that
>>>>>>>>>>> VSPs are somehow equivalent to exchange carriers.
>>>> They are not.
>>>>>>>>>>> 
>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet
>>>>>>>>>>> equivalent of
>>>>>>>>>>> involving long distance providers in POTS emergency
>>>> calls. They
>>>>>>>>>>> are neither
>>>>>>>>>>> necessary nor particularly helpful; they can't be
>>>> guaranteed to
>>>>>>>>>>> be within
>>>>>>>>>>> the
>>>>>>>>>>> emergency jurisdiction; depending on them actually
>>>> diminishes the
>>>>>>>>>>> efficacy
>>>>>>>>>>> of
>>>>>>>>>>> emergency service access. It does not help the caller, the
>>>>>>>>>>> emergency
>>>>>>>>>>> service,
>>>>>>>>>>> nor the third party to insist on the third party's
>>>> involvement.
>>>>>>>>>>> 
>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP
>>>>>>>>>>> involvement to
>>>>>>>>>>> yourself and others Brian. It is time to have a
>>>> reasoned debate.
>>>>>>>>>>> From my
>>>>>>>>>>> perspective, the argument that there is no "subscription"
>>>>>>>>>>> involved is
>>>>>>>>>>> patently
>>>>>>>>>>> false. There has to be a subscription of some description in
>>>>>>>>>>> order to get to
>>>>>>>>>>> the Internet. Yes, there is free public Internet
>>>> access (just as
>>>>>>>>>>> there are
>>>>>>>>>>> free courtesy phones on the PSTN and free access to
>> emergency
>>>>>>>>>>> services from
>>>>>>>>>>> pay phones. All these services are still connected to
>>>> the public
>>>>>>>>>>> Internet
>>>>>>>>>>> infrastructure and they all represent an "operator"
>> with some
>>>>>>>>>>> level of
>>>>>>>>>>> information about the caller.
>>>>>>>>>>> 
>>>>>>>>>>> With the over-emphasis on VSPs, what is missing
>> from the ECRIT
>>>>>>>>>>> and i3 models
>>>>>>>>>>> is the direct interface for querying the access network for
>>>>>>>>>>> subscriber data
>>>>>>>>>>> (should it prove necessary). These models need to
>>>> take the long
>>>>>>>>>>> view of how
>>>>>>>>>>> emergency calling is done in the Internet age; they
>>>> should not be
>>>>>>>>>>> protracting
>>>>>>>>>>> an unnecessary reliance on VSPs.
>>>>>>>>>>> 
>>>>>>>>>>> I have deleted the premature and prejudicial text from the
>>>>>>>>>>> subject heading.
>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG.
>>>>>>>>>>> 
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Martin
>>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: ecrit-bounces at ietf.org
>>>> [mailto:ecrit-bounces at ietf.org] On
>>>>>>>>>>> Behalf Of
>>>>>>>>>>> Hannes Tschofenig
>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM
>>>>>>>>>>> To: ecrit at ietf.org
>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
>>>>>>>>>>> considered harmful,
>>>>>>>>>>> at least given our current experiences
>>>>>>>>>>> 
>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT
>>>> contribution.
>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: geopriv-bounces at ietf.org
>>>>>>>>>>>> [mailto:geopriv-bounces at ietf.org] On Behalf Of Rosen, Brian
>>>>>>>>>>>> Sent: 26 October, 2009 23:10
>>>>>>>>>>>> To: geopriv at ietf.org
>>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered
>>>>>>>>>>>> harmful, at least given our current experiences
>>>>>>>>>>>> 
>>>>>>>>>>>> The notion behind -direct is to not use a service
>> provider to
>>>>>>>>>>>> place an emergency call.  Instead, the device
>> registers with
>>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the
>>>>>>>>>>>> call and the call is routed directly from the device
>>>> to the ESRP.
>>>>>>>>>>>> 
>>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea.
>>>>>>>>>>>> 
>>>>>>>>>>>> Emergency calling authorities like service
>> providers, a lot.
>>>>>>>>>>>> They like them because they can hold them
>>>> accountable, and the
>>>>>>>>>>>> service providers don't like theft of service, which is
>>>>>>>>>>>> something the emergency call guys have an analog to.
>>>>>>>>>>>> 
>>>>>>>>>>>> The facts are that where unaccountable access to emergency
>>>>>>>>>>>> calling is allowed, huge numbers of false calls
>>>> occur, with no
>>>>>>>>>>>> way to stop them, and no way to tell the good ones from the
>>>>>>>>>>>> bad ones.  This has been seen multiple times where
>> so called
>>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed.
>>>>>>>>>>>> 
>>>>>>>>>>>> -direct precisely duplicates simless calling.  The only
>>>>>>>>>>>> "registration" is an emergency registration, only emergency
>>>>>>>>>>>> calls are allowed, any device can make an emergency call if
>>>>>>>>>>>> all it has is a (radio) connection to any network.
>>>>>>>>>>>> We can predict, with a very high degree of
>>>> certainty, that the
>>>>>>>>>>>> feature will be horribly abused: for example to test that a
>>>>>>>>>>>> phone without a service plan works.
>>>>>>>>>>>> 
>>>>>>>>>>>> There have been studies which show tens of thousands of bad
>>>>>>>>>>>> calls with zero good ones.  Nearly every authority I know
>>>>>>>>>>>> where the regulator has insisted on simless
>> calling wants it
>>>>>>>>>>>> repealed.  There is one counter example I know
>> where the fact
>>>>>>>>>>>> that they got a couple, literally, of good calls among the
>>>>>>>>>>>> tens of thousands of bad calls was considered enough
>>>> reason to
>>>>>>>>>>>> put up with the problem.
>>>>>>>>>>>> 
>>>>>>>>>>>> Service providers give us information that may be useful: a
>>>>>>>>>>>> subscriber name and address for example, which is not
>>>>>>>>>>>> spoofable by the caller.  They have ways to trace callers,
>>>>>>>>>>>> especially bad callers.  They don't want their
>> systems abused
>>>>>>>>>>>> any more than the emergency calling authorities do.
>>>>>>>>>>>> 
>>>>>>>>>>>> This is a bad idea.  A very bad idea.  Please stop it.
>>>>>>>>>>>> 
>>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we
>>>>>>>>>>>> do, service providers are a good thing on an
>> emergency call.
>>>>>>>>>>>> We don't want them cut out.
>>>>>>>>>>>> 
>>>>>>>>>>>> Brian
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Geopriv mailing list
>>>>>>>>>>>> Geopriv at ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>> Ecrit at ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>> Ecrit at ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ecrit mailing list
>>>>>>>>>> Ecrit at ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Ecrit mailing list
>>>>>>>> Ecrit at ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 
>> 
>> 
>>