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

[Marc Linsner <mlinsner at cisco.com>]

Brian,

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 at 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 at 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 at 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 at 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 at ietf.org [mailto:ecrit-bounces at ietf.org]
>>>>> On Behalf Of Marc Linsner
>>>>> Sent: Thursday, October 29, 2009 12:32 PM
>>>>> To: Brian Rosen
>>>>> Cc: ecrit at 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 at 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 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
>>>>> 
>>> 
>>> 
>> 
>> 
> 
>