I didn't read anything in the draft that stated devices 'should' use this
mechanism (if it's there, it needs removed). I read it more as a device
'could' use this mechanism (as in an alternative to other mechanisms).
Further, since the ESRP is controlled by the PSAP, it certainly would be a
PSAP policy decision whether to support this mechanism. As without the ESRP
support of unknown UA registrations, the mechanism doesn't work.
BTW, the term 'unregistered' is not in phonebcp. I think your are
stretching the 'normal call path' to include registration with something(?).
I find nothing in phonebcp that disallows 'direct' calls to an ESRP. If I
contact an ESRP from my UA 'directly', as long as the PSAP can call-back
using the Contact header I sent in the invite and my AOR leads back to my
UA, I've satisfied phonebcp.
What am I missing?
-Marc-
On 10/29/09 4:35 PM, "Brian Rosen" <br@brianrosen.net> wrote:
> The IETF writing standards that describe how devices should bypass their
> service provider and place emergency calls direct is not a PSAP policy
> issue.
>
> I'm satisfied with the current -phonebcp dictum to send calls on the normal
> call path. For an "unregistered" device, that will not allow any "calls"
> including emergency calls.
>
> I discussed this draft on the NENA LTD meeting this morning. That may
> generate some list discussion from some PSAP people who are subscribed. I
> would also like to hear from more PSAP folks on this subject.
>
> Brian
>
>
> On 10/29/09 3:27 PM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>
>> These are all PSAP policy decisions. Just as it's a PSAP policy decision to
>> support the suggested mechanism in the draft. Existence of the document
>> describing the mechanism doesn't force PSAP policy.
>>
>> I personally would like to see some PSAPs and/or PS jurisdictions line up
>> behind the draft before it proceeds, but I don't see any harm in it going
>> forward.
>>
>> Of course, I'm dreaming about this special place where a PSAP actually wants
>> to enable communication with all their customers and not force them to be a
>> member of a special club.
>>
>> [non-chair hat on]
>>
>> -Marc-
>>
>>
>> On 10/29/09 2:35 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>>
>>> Thank you. That is what I meant, and you said it better than I was going
>>> to.
>>>
>>> We may also have some transitive relationships: that is, if there is a
>>> "local" PSAP that trusts that they have done so, other PSAPs may trust that
>>> they have done so.
>>>
>>> Brian
>>>
>>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
>>> wrote:
>>>
>>>> I suspect that what Brian is saying is that anyone can be a service
>>>> provider
>>>> (or whatever else you want to call it) in this case provided that:
>>>>
>>>> 1) they make that agreement with the PSAP providers they route calls
>>>> to;
>>>>
>>>> 2) they authenticate the calls requests to a level of security that
>>>> meets
>>>> the PSAPs (and any legal) requirements;
>>>>
>>>> 3) the PSAP trusts that they have done so.
>>>>
>>>> While this would normally be what we would understand as public
>>>> telecommuncation operators, it doesn't mean they have to be.
>>>>
>>>> regards
>>>>
>>>> Keith
>>>>
>>>>> -----Original Message-----
>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
>>>>> On Behalf Of Marc Linsner
>>>>> Sent: Thursday, October 29, 2009 12:32 PM
>>>>> To: Brian Rosen
>>>>> Cc: ecrit@ietf.org
>>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
>>>>> considered
>>>>>
>>>>> Brian,
>>>>>
>>>>> Please define what you consider to be a service provider.
>>>>>
>>>>> Is Skype a service?
>>>>> Is Jabber a service?
>>>>> Is Google Voice a service?
>>>>> Is mydomain.com hosted on a commercial site a service?
>>>>> Is mydomain.com hosted on a home server a service?
>>>>> Is myEnterpriseVoIP.com a service?
>>>>>
>>>>> So, what you are saying that if I can make calls via all of
>>>>> the above, it's OK for all of the above to contact an ESRP?
>>>>>
>>>>> Are you requiring that I have a full-time proxy on-line for
>>>>> mydomain.com or can I simply run a transient UA and dynamic DNS?
>>>>>
>>>>> -Marc-
>>>>>
>>>>>
>>>>>
>>>>> On 10/28/09 11:17 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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@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@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@ordinary_citizen.com.
>>>>>>>
>>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But
>>>>>>> Joey@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@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@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@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@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@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@ietf.org
>>>>> [mailto:ecrit-bounces@ietf.org] On
>>>>>>>>>>>> Behalf Of Hannes Tschofenig
>>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM
>>>>>>>>>>>> To: ecrit@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@ietf.org
>>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian
>>>>>>>>>>>> Sent: 26 October, 2009 23:10
>>>>>>>>>>>> To: geopriv@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@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ecrit mailing list
>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>
>>>
>>
>>
>
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
